Re: [patch] libpq one-row-at-a-time API

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Marko Kreen <markokr(at)gmail(dot)com>, Postgres Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [patch] libpq one-row-at-a-time API
Date: 2012-07-24 16:59:13
Message-ID: 23861.1343149153@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> I think the dummy copy of PGresult is plausible (if by that you mean
> optimizing PQgetResult when in single row mode). That would be even
> better: you'd remove the need for the rowbuf mode.

I haven't spent any time looking at this, but my gut tells me that a big
chunk of the expense is copying the PGresult's metadata (the column
names, types, etc). It has to be possible to make that cheaper.

One idea is to rearrange the internal storage so that that part reduces
to one memcpy(). Another thought is to allow PGresults to share
metadata by treating the metadata as a separate reference-counted
object. The second could be a bit hazardous though, as we advertise
that PGresults are independent objects that can be manipulated by
separate threads. I don't want to introduce mutexes into PGresults,
but I'm not sure reference-counted metadata can be safe without them.
So maybe the memcpy idea is the only workable one.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message karavelov 2012-07-24 17:09:38 Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)
Previous Message Marko Kreen 2012-07-24 16:57:09 Re: [patch] libpq one-row-at-a-time API