From: | "V S P" <toreason(at)fastmail(dot)fm> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "postgres general" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: [Q] optmizing postgres for 'single client' / many small queries |
Date: | 2009-09-02 18:40:20 |
Message-ID: | 1251916820.31570.1332901689@webmail.messagingengine.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Well, actually
somebody has written a C++ ORM
that allows to do things (just a sketch)
class L: CDbCapable
{
public:
int prop1;
int prop2;
}
class A: CDbCapable
{
QArray<L> list_of_props_xyz;
}
int main ()
{
A inst1;
inst1.create_or_update_DbSchemaIfNeeded();
inst1.readFromDb();
//modifying something
inst1.writeToDb();
}
As it is well known C++ lack of Reflection prevents it from having
standardise Data serialization
libraries to files or to Databases.
So in-house a mechanism was developed to do the above. It took some
time and it is not possible to just yank it out.
Of course, internally in the ORM's implementation a somewhat
questionable decision was made that
to process arrays of 'children' for a given instance would require
separate SQL statements.
That's where the problem comes from, I understand what needs to be done
to redesign the approach/etc. And that
will take more time than currently is available.
Therefore, I just wanted to ask if there there are some things in Pg
that can I can experiment with
(local client/server communcations via IPC, reducing the speed of SQL
parses, any other possible tricks)
Thank you in advance
On Wed, 02 Sep 2009 14:26 -0400, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "V S P" <toreason(at)fastmail(dot)fm> writes:
> > The application typicall goes like this
>
> > select id, child_tb_key_id, <fields with parms> from tb1
>
> > then for each selected row above
> > select from the child table do a select (like the above)
>
> > and so on -- many levels deep
>
> Seems like you need to fix your data representation so that this
> operation can be collapsed into one query. The main problem looks
> to be a bogus decision to have separate child tables rather than
> one big table with an extra key column.
>
> regards, tom lane
--
Vlad P
author of C++ ORM http://github.com/vladp/CppOrm/tree/master
--
http://www.fastmail.fm - mmm... Fastmail...
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-09-02 18:45:39 | Re: [Q] optmizing postgres for 'single client' / many small queries |
Previous Message | Tom Lane | 2009-09-02 18:26:01 | Re: [Q] optmizing postgres for 'single client' / many small queries |