From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Ayush Vatsa <ayushvatsa1810(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, michael(at)paquier(dot)xyz |
Subject: | Re: Pgstattuple on Sequences: Seeking Community Feedback on Potential Patch |
Date: | 2024-08-26 17:26:27 |
Message-ID: | Zsy6w_yW2QKYSo_m@nathan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 26, 2024 at 09:14:27PM +0530, Ayush Vatsa wrote:
> Given the situation, I see two potential paths forward:
> *1/ Reintroduce Support for Sequences in pgstattuple*: This would be a
> relatively small change. However, it's important to note that the purpose
> of pgstattuple is to provide statistics like the number of tuples, dead
> tuples, and free space in a relation. Sequences, on the other hand, return
> only one value at a time and don´t have attributes like dead tuples.
>
> [...]
>
> *2/ Explicitly Block Sequence Support in pgstattuple*: We could align
> sequences with other unsupported objects, such as foreign tables, by
> providing a more explicit error message.
While it is apparently pretty uncommon to use pgstattuple on sequences,
this is arguably a bug that should be fixed and back-patched. I've CC'd
Michael Paquier, who is working on sequence AMs and may have thoughts. I
haven't looked at his patch set for that, but I'm assuming that it might
fill in pg_class.relam for sequences, which would have the same effect as
option 1.
I see a couple of other places we might want to look into as part of this
thread. Besides pgstattuple, I see that pageinspect and pg_surgery follow
a similar pattern. pgrowlocks does, too, but that one seems intentionally
limited to RELKIND_RELATION. I also see that amcheck explicitly allows
sequences:
/*
* Sequences always use heap AM, but they don't show that in the catalogs.
* Other relkinds might be using a different AM, so check.
*/
if (ctx.rel->rd_rel->relkind != RELKIND_SEQUENCE &&
ctx.rel->rd_rel->relam != HEAP_TABLE_AM_OID)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("only heap AM is supported")));
IMHO it would be good to establish some level of consistency here.
--
nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2024-08-26 17:31:47 | Re: Proposal to have INCLUDE/EXCLUDE options for altering option values |
Previous Message | Amonson, Paul D | 2024-08-26 17:09:35 | RE: Proposal for Updating CRC32C with AVX-512 Algorithm. |