| From: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Modest proposal to extend TableAM API for controlling cluster commands |
| Date: | 2022-06-16 02:24:59 |
| Message-ID: | 1D6CF0FB-D7A8-4524-B09A-46DDCC61EF1A@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Jun 15, 2022, at 7:21 PM, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> wrote:
>
>> If a user does that for a table that doesn't support clustering, well, I don't
>> see what's gained by not erroring out.
>
> Perhaps they want to give the TAM information about which index to use for sorting, on those occasions when the TAM's logic dictates that sorting is appropriate, but not in response to a cluster command.
I should admit that this is a bit hack-ish, but TAM authors haven't been left a lot of options here. Index AMs allow for custom storage parameters, but Table AMs don't, so getting information to the TAM about how to behave takes more than a little slight of hand. Simon's proposal from a while back (don't have the link just now) to allow TAMs to define custom storage parameters would go some distance here.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2022-06-16 02:30:04 | Re: Modest proposal to extend TableAM API for controlling cluster commands |
| Previous Message | Mark Dilger | 2022-06-16 02:21:42 | Re: Modest proposal to extend TableAM API for controlling cluster commands |