Hacker News Reader

Comment by s_kilk | Hacker News Reader

Hi All,

I've been working on this project on-and-off for a few years now, and thought it was time to show it to the public.

The Gist:

BedquiltDB is a vaguely mongodb-inspired json store built on top of PostgreSQL's jsonb column type. It does the things you'de expect, creating _id fields automatically, creating tables on the first write, etc.

It is implemented as a postgres extension (a horrible lump of PL/PgSQL), and client libraries for python, node and clojure.

While I'm not using it in production for anything, it is pretty well tested, and I had fun making it, which is what really matters :)

Questions welcome!

View on HN

Any particular reason to choose PL/PgSQL over other extension languages?

It seemed to be the most performant option available, aside from C.

I wouldn't be opposed to re-writing in a more-performant extension language if needed.

EDIT: also, PL/PgSQL is installed by default, and I wanted to see if I could get this project to work without any other dependencies aside from a base PostgerSQL 9.4 installation.

Yes, it makes sense to write it in whatever was most performant

Not requiring any external dependencies is a huge plus in my book.

+23478723497894235787345897435 for this!

I loathe and detest dependencies! Just saying.

But how else can you make sure your pad_left function is well written and widely tested?

Especially when PL/V8 seems natural when working on JSON(b).

It even is much faster compared to PL/pgSQL (at least in a project I've been working on lately).

> It even is much faster compared to PL/pgSQL (at least in a project I've been working on lately)

That's good to hear. At the time I had read somewhere that PL/V8 can be slow because it needs to cast/convert data back and forth between javascript and native Postgres representations. It's possible that that assessment is wrong, however.

Ofc make your own benchmarks before taking PLV8 into consideration.

In my case PL/pgSQL FOR loop was particularly slow; lack of builtin data structures like map or stack (though stack is emulated in V8 via array) caused performance problems – array operations are really slow in PL/pgSQL (compared to V8), instead of using map I've use indexed temporary table (creation of such is quite costly).

Still you might have a point here – PL/pgSQL stores execution plans with the function, so there is a chance of being more efficient here.

Did you try using plain SQL with unnest()?

PL/V8 maintainer here - yes, JSON/JSONB structures are brought through the C++/Javascript membrane, but for the most part it doesn't seem too slow (full disclosure, i wrote a mongo clone on PL/V8 a few years ago).

but, there is also the ability to simply query from inside a function using plv8.execute(), which gives you the ability to use JSONB operators, which are much faster.

Years? But JSONB hasn't been alive for such a long time.

Maybe they started with hstore and replaced that over time.

Reply on news.ycombinator.com