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.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
