From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Optimising compactify_tuples() |
Date: | 2020-09-08 17:37:54 |
Message-ID: | CA+hUKG+7YRyXvL2pK0FkzM=ZCFPZ9TEwfi3rZJGUO3yoCWWkHQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Sep 9, 2020 at 3:47 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> On Tue, 8 Sep 2020 at 12:08, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > One thought is that if we're going to copy everything out and back in
> > again, we might want to consider doing it in a
> > memory-prefetcher-friendly order. Would it be a good idea to
> > rearrange the tuples to match line pointer order, so that the copying
> > work and also later sequential scans are in a forward direction?
>
> That's an interesting idea but wouldn't that require both the copy to
> the separate buffer *and* a qsort? That's the worst of both
> implementations. We'd need some other data structure too in order to
> get the index of the sorted array by reverse lineitem point, which
> might require an additional array and an additional sort.
Well I may not have had enough coffee yet but I thought you'd just
have to spin though the item IDs twice. Once to compute sum(lp_len)
so you can compute the new pd_upper, and the second time to copy the
tuples from their random locations on the temporary page to new
sequential locations, so that afterwards item ID order matches offset
order.
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2020-09-08 17:53:52 | Re: Improving connection scalability: GetSnapshotData() |
Previous Message | James Coleman | 2020-09-08 17:27:50 | Re: PROC_IN_ANALYZE stillborn 13 years ago |