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
