Re: Postgres NoSQL emulation

From: "Pierre C" <lists(at)peufeu(dot)com>
To: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Postgres NoSQL emulation
Date: 2011-05-11 11:14:46
Message-ID: op.vvbdiwdceorkce@apollo13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


> why even have multiple rows? just jam it all it there! :-D

LOL

But seriously, when using an ORM to stuff an object hierarchy into a
database, you usually get problems with class inheritance, and all
solutions suck more or less (ie, you get a zillion tables, with assorted
pile of JOINs, or stinky key/attributes schemes where all attributes end
up as TEXT, or a table with 200 columns, most of them being NULL for a
given line).

NoSQL guys say "hey just use NoSQL !".

In a (common) case where the classes have some fields in common and othen
searched, and that the DB needs to know about and access easily, those
become columns, with indexes. Then the other fields which only occur in
some derived class and are not very interesting to the DB get shoved into
a hstore. The big bonus being that you use only one table, and the "extra"
fields can still be accessed and indexed (but a little slower than a
normal column). However I believe hstore can only store TEXT values...

Could be interesting. Or not.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Mason S 2011-05-11 11:56:51 Re: partition query on multiple cores
Previous Message Prodan, Andrei 2011-05-11 11:08:44 'Interesting' prepared statement slowdown on large table join