From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: logical changeset generation v6.2 |
Date: | 2013-10-22 16:25:31 |
Message-ID: | 5266A6FB.3050105@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-10-22 16:30:26 | Re: logical changeset generation v6.2 |
Previous Message | Andres Freund | 2013-10-22 16:23:53 | Re: logical changeset generation v6.2 |