Re: REPACK and naming - Mailing list pgsql-hackers

From David Rowley
Subject Re: REPACK and naming
Date
Msg-id CAApHDvpNNZg2S92K_BjVJa4xemQKvgZ5o-RDWxPPbL_hF6sW=A@mail.gmail.com
Whole thread Raw
In response to Re: REPACK and naming  (Antonin Houska <ah@cybertec.at>)
Responses Re: REPACK and naming
List pgsql-hackers
On Fri, 19 Sept 2025 at 23:58, Antonin Houska <ah@cybertec.at> wrote:
> Admittedly I haven't thought about clause like ORDER BY yet, but I wonder if
> it'd really be useful. My understanding is that the purpose of clustering is
> to make index scan more efficient: with a clustered table, the heap tuples
> pertaining to given index tuple should be located on the same page, so the
> heap access is not that random.

I imagine that's true most of the time, but it could also be so that
fewer pages are dirtied when an UPDATE updates a set or rows with the
same or similar clustered column values.

> If IOT-AM table does not have anything like index, I imagine it has some kind
> of ordering information in the system catalog. Without that the query planner
> can hardly utilize the ordering. In such case REPACK should use the catalog
> information on ordering rather than accept arbitrary ORDER BY clause.

Well, it would be impossible to insert records without some metadata
to indicate the IOT keys...

You might assume that someone might change their mind one day about
the chosen order and wish to change it. My point was about leaving the
door open to support that by having some native syntax that could be
used to trigger that change.

David



pgsql-hackers by date:

Previous
From: Antonin Houska
Date:
Subject: Re: REPACK and naming
Next
From: Antonin Houska
Date:
Subject: Re: REPACK and naming