Re: [patch] libpq one-row-at-a-time API - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [patch] libpq one-row-at-a-time API
Date
Msg-id 23861.1343149153@sss.pgh.pa.us
Whole thread Raw
In response to Re: [patch] libpq one-row-at-a-time API  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: [patch] libpq one-row-at-a-time API  (Merlin Moncure <mmoncure@gmail.com>)
List pgsql-hackers
Merlin Moncure <mmoncure@gmail.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


pgsql-hackers by date:

Previous
From: Marko Kreen
Date:
Subject: Re: [patch] libpq one-row-at-a-time API
Next
From: karavelov@mail.bg
Date:
Subject: Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)