On 2013-10-22 19:25:31 +0300, Heikki Linnakangas wrote:
> 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..
That's not sufficient if you want to continue writing in the primary
backend though which isn't an uninteresting thing.
I am not saying that parallel XXX is a sufficient reason for this, just
that it might a be a co-benefactor.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services