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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
