On 22.10.2013 19:23, Andres Freund wrote:
On 2013-10-22 19:19:19 +0300, Heikki Linnakangas wrote:
On 22.10.2013 19:12, Andres Freund wrote:
On 2013-10-18 20:26:16 +0200, Andres Freund wrote:
4) Store both (cmin, cmax) for catalog tuples.
BTW: That would have the nice side-effect of delivering the basis of
what you need to do parallel sort in a transaction that previously has
performed DDL.
Currently you cannot do anything in parallel after DDL, even if you only
scan the table in one backend, because operators et al. have to do
catalog lookups which you can't do consistently since cmin/cmax aren't
available in both.
Parallel workers will need cmin/cmax for user tables too, to know which
tuples are visible to the snapshot.
The existing proposals were mostly about just parallelizing the sort and
similar operations, right? In such scenarios you really need it only for
the catalog.
But we could easily generalize it for user data too. We should even be
able to only use "wide cids" when we a backend needs it it since
inherently it's only needed within a single transaction.
Or just hand over a copy of the combocid map to the worker, along with
the snapshot. Seems a lot simpler than this wide cids business..
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
