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

Friendlier SQL with DuckDB

duckdb.org

Post reply on HN
Print view View original

131–134 of 134 posts

Re: Friendlier SQL with DuckDB

#131

Post by fijiaarone » 

  SELECT * EXCLUDE (jar_jar_binks, midichlorians) FROM star_wars
Error: columns not found

On further investigation, It seems that someone had maliciously injected lots of bogus data into the production database. We tried to clean up by truncating tables and dropping columns, but in the end it was easier to just restore from backup prior to 1999.

There still seems to be some residual corruption, most predominantly around mos_eisley and jabbas_palace data, and we had to truncate the end of Return of the Jedi, but not much was lost there.

Re: Friendlier SQL with DuckDB

#132

Post by nojvek »

pholanda wrote: post #16
eis wrote: post #6

I was just yesterday exploring DuckDB and it looked very promising but I was very surprised to find out that indexes are not persisted (and I assume that means they must fit in RAM). > Unique and primary key indexes are rebuilt upon startup, while user-defined indexes are discarded. The second part with just discarding previously defined indexes is super surprising. https://duckdb.org/docs/sql/indexes This was an ins…

Hey eis, you are correct. We do not support index storage in our latest release. I am currently implementing this, and it is in a fairly advanced stage. So it should be featured in the next release. This took a little while because we use a fairly modern index structure with no literature definition on how to buffer manage it.

Will the persistent indices still be built on ART indexes? ART is a great choice of data structure. Fast lookups, range queries and prefix queries.

Typesense DB (Typesense.org) under the hood also uses ART as the base datastructure for fast full text search queries.

So I assume it would be straightforward to build an text search engine on top of duck DB and utilize ART indices to do even more lovely things.

Re: Friendlier SQL with DuckDB

#133

Post by padmi »

Friendlier sql is MySQL "insert into set".

Normal insert, hard to read:

INSERT INTO table1 ( field1, field2, field3, ... ) VALUES ('value1', 'value2', 'value3', ... );

vs

Easier to read:

INSERT INTO table1 SET field1='value1', field2='value2', field3='value3', ...

Re: Friendlier SQL with DuckDB

#134

Post by chrisjc »

1egg0myegg0 wrote: post #17
chrisjc wrote: post #14

What are some potential long-term liabilities we might see in choosing to adopt duckdb today? Obviously there will be a desire to monetize this project, if not for the very simple reason of subsidizing the cost of its development and maintenance. I love everything I hear and see about this project, but it makes me nervous to recommend this internally due to it not only being in such an early stage, but also bc of any…

Let me see if I can assuage some of your concerns! First off - DuckDB is MIT licensed, so you are welcome to use and enhance it essentially however you please! DuckDB Labs is a commercial entity that offers commercial support and custom integrations. ( https://duckdblabs.com/ ). If the MIT DuckDB works for what you need, then you are all set no matter what! However, much of the IP for DuckDB is owned by a foundation,…

Absolutely. I think DuckDB's future is bright and excited to hopefully work with it in the near future.
Post reply on HN