| 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:19:19 |
| Message-ID: | 5266A587.1020306@vmware.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
- Heikki
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2013-10-22 16:23:53 | Re: logical changeset generation v6.2 |
| Previous Message | Andres Freund | 2013-10-22 16:12:13 | Re: logical changeset generation v6.2 |