Re: Critical performance problems on large databases - Mailing list pgsql-general

From Gunther Schadow
Subject Re: Critical performance problems on large databases
Date
Msg-id 3CB5C521.4000100@aurora.regenstrief.org
Whole thread Raw
In response to Critical performance problems on large databases  (Gunther Schadow <gunther@aurora.regenstrief.org>)
Responses Re: Critical performance problems on large databases  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Tom Lane wrote:

> Gunther Schadow <gunther@aurora.regenstrief.org> writes:
>
>>The constructive responses suggested that I use LIMIT/OFFSET and
>>CURSORs. I can see how that could be a workaround the problem, but
>>I still believe that something is wrong with the PostgreSQL query
>>executer. Loading the entire result set into a buffer without
>>need just makes no sense.
>>
>
> The Postgres backend does not do that.  Most of the frontend client-side
> libraries do, but feel free to write one that does not.


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?

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

thanks for the info,
-Gunther





--
Gunther Schadow, M.D., Ph.D.                    gschadow@regenstrief.org
Medical Information Scientist      Regenstrief Institute for Health Care
Adjunct Assistant Professor        Indiana University School of Medicine
tel:1(317)630-7960                         http://aurora.regenstrief.org



pgsql-general by date:

Previous
From: Jeff Eckermann
Date:
Subject: Re: Postgresql goes into recovery mode ....
Next
From: "Papp, Gyozo"
Date:
Subject: Re: SPI_execp() failed in RI_FKey_cascade_del()