Re: libpq Alternate Row Processor

From: Kyle Gearhart <kyle(dot)gearhart(at)indigohill(dot)io>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: libpq Alternate Row Processor
Date: 2017-02-06 01:49:20
Message-ID: BLUPR14MB01620F5D037B2611C8F42EFDFA400@BLUPR14MB0162.namprd14.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]:
> Kyle Gearhart <kyle(dot)gearhart(at)indigohill(dot)io> writes:
>> The guts of pqRowProcessor in libpq does a good bit of work to maintain the internal data structure of a PGresult. There are a few use cases where the caller doesn't need the ability to access the result set row by row, column by column using 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 patch and 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2017-02-06 01:57:56 Re: Index corruption with CREATE INDEX CONCURRENTLY
Previous Message Haribabu Kommi 2017-02-06 01:27:12 Re: [REVIEW] macaddr 64 bit (EUI-64) datatype support