Re: Critical performance problems on large databases

Поиск
Список
Период
Сортировка
От Gunther Schadow
Тема Re: Critical performance problems on large databases
Дата
Msg-id 3CB5C521.4000100@aurora.regenstrief.org
обсуждение исходный текст
Ответ на Critical performance problems on large databases  (Gunther Schadow <gunther@aurora.regenstrief.org>)
Ответы Re: Critical performance problems on large databases  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Jeff Eckermann
Дата:
Сообщение: Re: Postgresql goes into recovery mode ....
Следующее
От: "Papp, Gyozo"
Дата:
Сообщение: Re: SPI_execp() failed in RI_FKey_cascade_del()