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
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 .... |