Re: Critical performance problems on large databases

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

Tom Lane wrote:

> Gunther Schadow <gunther(at)aurora(dot)regenstrief(dot)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(at)regenstrief(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Papp, Gyozo 2002-04-11 17:31:20 Re: SPI_execp() failed in RI_FKey_cascade_del()
Previous Message Jeff Eckermann 2002-04-11 17:10:13 Re: Postgresql goes into recovery mode ....