On Tue, Jul 24, 2012 at 1:49 PM, Merlin Moncure <mmonc...@gmail.com> wrote: > On Tue, Jul 24, 2012 at 1:33 PM, Merlin Moncure <mmonc...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers