On Tue, Jul 24, 2012 at 1:49 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Tue, Jul 24, 2012 at 1:33 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
>> The 'source' result (or source data that would be copied into the
>> destination result) would be stored in the PGconn, right? So, the idea
>> is that when you set up single row mode the connection generates a
>> template PGconn which is then copied out repeatedly during row-by-row
>> processing. I like it, but only if we're reasonably confident the
>> PGresult can be sufficiently optimized like that.
>
> hm, PGresAttDesc is unfortunately in the public header and as such
> probably can't be changed?
It can't -- at least not without breaking compatibility. So, as
attractive as it sounds, it looks like a memcpy based PGresult copy is
out unless we break the rules change it anyways (with the probably
safe assumption that the only userland code that cares is libpqtypes,
which we'd certainly change).
However, it's not clear that a shared metadata implementation would
require a mutex -- if you stored the shared data in the conn and were
willing to walk the results in the event the PGconn was freed before
the results, you'd probably be ok. That's really unpleasant though.
Either way, it looks like there's plausible paths to optimizing
repeated result fetch without having expose an alternate data-fetching
API and that the proposed implementation doesn't appear to be a wall
in terms of getting there. So I'm firmly in the non-exposed-rowbuf
camp, even if we can't expose an optimal implementation in time for
9.2.
merlin