Re: Critical performance problems on large databases

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gunther Schadow <gunther(at)aurora(dot)regenstrief(dot)org>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Critical performance problems on large databases
Date: 2002-04-12 20:47:30
Message-ID: 10433.1018644450@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> Thanks, Tom, that's helpful! So, are you saying the the psql
> client does all the buffering and not the server? Is the
> buffering mandatory when using the libpq API? When you say
> "most frontend client side libraries" do you know of any
> exceptions who don't do that? Is the odbc client doing this
> too?

Yup, yup, and all the ones I know about but I do not know the details of
several (including jdbc and odbc).

> I can see myself fixing this problem, but would like to know
> if there is something else already?

Not that I know of.

I could imagine extending libpq reasonably straightforwardly:
assuming that you use PQsendQuery/PQgetResult, you could add a
PQgetPartialResult() that would extract the rows-received-so-far.
When it fails to get any more rows, a final PQgetResult would get the
query's success/fail status and possible error message. Not sure about
all the details here; if you want to pursue it, start a discussion on
pgsql-interfaces.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Ian Harding 2002-04-12 21:09:15 Re: Nested Loop WAS: VACUUM ANALYZE makes things
Previous Message Ian Harding 2002-04-12 20:43:18 Nested Loop WAS: VACUUM ANALYZE makes things worse!