Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Natural-SQL-7B, a strong text-to-SQL model

github.com

Post reply on HN
Print view View original

101–110 of 171 posts

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#101

Post by int_19h »

itsoktocry wrote: post #9

> complex questions like above. This is cool, and up my alley. But that's not a complex question, it's a basic analytics question. Most analysts will be able to write something like that in their sleep. I've been using ChatGPT for writing SQL, and it's mediocre. But it'll get better, I'm sure.

Even GPT-4 often writes queries with redundant subqueries, excessive nesting or joins etc. I don't think that's particularly valuable.

On the other hand, telling GPT to generate SQL to query a data store as part of solving some task that requires inference from facts captured in that data store works surprisingly well - better than "function calls" with JSON, in my opinion. While such generated queries are also suboptimal, they still capture the intent correctly, and GPT is surprisingly adept at using nested subqueries to get the answer it needs in a single query. And when such generated SQL is wrong, it usually fails to parse (e.g. due to typos in field names), at which point you can just feed the error message back to the model and have it correct that.

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#102

Post by lolpanda »

I don't think any of those text-to-sql models are solving the right problems. The hard part is not syntax or I don't know how to write a group by query. Most data scientists and engineers spend more time on understanding the meaning of the data. One cannot simply look at a 50 columns table in Snowflake and guess what columns are by their names. For example, we have 10 columns in one tables, all named ...price. We have to go to wiki to find the actual meaning or read the DBT definitions. I cannot trust any queries that models produce because they don't understand the data; they only understand the query syntax.

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#103

Post by ComputerGuru »

fifilura wrote: post #99
ComputerGuru wrote: post #97

Earlier quoted context omitted.

LATERAL first available in PostgreSQL 9.3 (2013), but still not available in SQLite.

SQLite has RECURSIVE, so you can generate a table with all numbers using something like: WITH RECURSIVE cnt(x) AS ( SELECT 1 UNION ALL SELECT x+1 FROM cnt LIMIT 5 ) SELECT x FROM cnt; And then do a regular CROSS JOIN on that table.

But generating a table with all numbers was just a throwaway example of the LATERAL JOIN syntax/use, and (hopefully) not what you'd actually use it for in the real world.

It's not clear to me that (mathematically) a lateral join can be reduced to a recursive cte (and if the performance of a recursive cte would be acceptable for the cases where it does work as a substitute).

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#104

Post by klabb3 »

Keyframe wrote: post #39
CharlesW wrote: post #38

Earlier quoted context omitted.

> Call it what it is, source available. Also, it's only weights AFAICT — no source training data/code is available.

Shareware?

Yep. Open source means you can build and modify it. If not, it’s not open source.

You know it’s a bad timeline when releasing the equivalent of a binary is considered “open”.

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#105

Post by ttfkam »

gavinray wrote: post #64
ttfkam wrote: post #58

Earlier quoted context omitted.

I love LATERALs, but this still fits within set theory and a bulk application rather than an iterative for-loop. It may even be implemented as a for-loop within the engine, but SQL being declarative abstracts that away from the query interface. It's sets all the way down. A set of f(x) is still a set.

Lets get even more cursed then: CREATE TEMP TABLE temp_results(value int, value_squared int); DO $$ DECLARE r int; BEGIN FOR r IN SELECT generate_series FROM generate_series(1,5) LOOP INSERT INTO temp_results VALUES (r, r * r); END LOOP; END$$; SELECT * FROM temp_results;

Ha! plpgsql's seemingly sole purpose is to inject imperative code into a set-based environment. Probably does it more smoothly than most pl languages, but that's at the cost of imperative clarity.

But you're right. Postgres does allow for-loops like this. (They're also slower than the equivalent set-oriented approach.)

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#106

Post by joshhart »

lolpanda wrote: post #102

I don't think any of those text-to-sql models are solving the right problems. The hard part is not syntax or I don't know how to write a group by query. Most data scientists and engineers spend more time on understanding the meaning of the data. One cannot simply look at a 50 columns table in Snowflake and guess what columns are by their names. For example, we have 10 columns in one tables, all named ...price. We hav…

At Databricks we have an LLM that is fine-tuned to do the problem you raise -

https://www.databricks.com/blog/announcing-public-preview-ai...

Many customers like it a lot. Although perhaps in your case if there are many pricing details it may not be quite accurate.

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#107

Post by koolba »

fifilura wrote: post #69
gavinray wrote: post #64

Earlier quoted context omitted.

Lets get even more cursed then: CREATE TEMP TABLE temp_results(value int, value_squared int); DO $$ DECLARE r int; BEGIN FOR r IN SELECT generate_series FROM generate_series(1,5) LOOP INSERT INTO temp_results VALUES (r, r * r); END LOOP; END$$; SELECT * FROM temp_results;

Uw you win, I guess. Already started to think what I would write in that code review comment ;)

At the very least mention that re-running the SELECT in the same connection would include the prior results as well because they are preserved across commands within the same connection.

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#108

Post by ako »

3rd3 wrote: post #100
ComputerGuru wrote: post #98

Earlier quoted context omitted.

For this example, nothing. It would be useful where neither of the two SELECT queries is a subset/superset of the other. (Not saying you didn't know that.)

Could you give an example?

This will be useful if you have a table with some related history records, e.g., products with product price history, and you want to get the latest price. The lateral join would get all prices for the current product, sort them by date and then pick the top row.

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#109

Post by bagels »

rgbrgb wrote: post #21

So it looks like it scores 76.5% on SQL-Eval [0], a bit behind GPT-4 at 83% and sqlcoder-15b at 78%. What kind of applications would this be useful for? What can you build with an AI data science intern that's right 75% of the time? As a programmer who always has to look stuff up when I SQL, I could definitely see asking something like this for a first draft of a query but it seems like I'm slightly better off asking…

I know sql pretty well, but every once in a while doing things like percentiles come up where I don't remember the exact incantations to get the window syntax right. Things like this can save some googling and documentation reading. I can read it to see if it makes sense, and execute it. I can create tests for the output to verify. Can save a lot of time. If it's wrong, I use the fallback of googling for examples.

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#110

Post by ako »

calvinmorrison wrote: post #91
fifilura wrote: post #73

Earlier quoted context omitted.

Just that deeply inside that forest of functions you just wrote is the inner join that the SQL query would do in a couple of lines of code embedded.

more like, when it comes to complex data structures and logic, i will do that outside of sql. I'll do a join with sql no problem, by the time we're doing multiple inner joins I usually prefer to just do multiple sql queries. I don't care about performance that badly.

That’ll often not scale to millions of records. Letting the database optimizer find the optimal execution path instead of doing it procedurally elsewhere might result in “finishes in 5 minutes”, versus “doesn’t fit in a night”.
Post reply on HN