Re: [HACKERS] libpq Alternate Row Processor

Поиск
Список
Период
Сортировка
От Kyle Gearhart
Тема Re: [HACKERS] libpq Alternate Row Processor
Дата
Msg-id BLUPR14MB01620F5D037B2611C8F42EFDFA400@BLUPR14MB0162.namprd14.prod.outlook.com
обсуждение исходный текст
Ответ на Re: [HACKERS] libpq Alternate Row Processor  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] libpq Alternate Row Processor  (Kyle Gearhart <kyle.gearhart@indigohill.io>)
Список pgsql-hackers
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]:
> Kyle Gearhart <kyle.gearhart@indigohill.io> writes:
>> The guts of pqRowProcessor in libpq does a good bit of work to maintain the internal data structure of a PGresult.
Thereare a few use cases where the caller doesn't need the ability to access the result set row by row, column by
columnusing PQgetvalue.  Think of an ORM that is just going to copy the data from PGresult for each row into its own
structures.

> It seems like you're sort of reinventing "single row mode":
https://www.postgresql.org/docs/devel/static/libpq-single-row-mode.html

> Do we really need yet another way of breaking the unitary-query-result abstraction?


If it's four times faster...then the option should be available in libpq.  I'm traveling tomorrow but will try to get a
patchand proof with pgbench dataset up by the middle of the week.   

The performance gains are consistent with Jim Nasby's findings with SPI.

Kyle Gearhart



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Haribabu Kommi
Дата:
Сообщение: Re: [HACKERS][REVIEW] macaddr 64 bit (EUI-64) datatype support
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY