> You state that the > information pgstattuple provides isn't really useful for sequences, so > that means there's no real reason to do (1) That's correct, but we should consider that up until v11, sequences were supported in pgstattuple. Their support was removed unintentionally (I believe so). Therefore, it might be worth discussing whether it makes sense to reinstate support for sequences.
> why you think that the current one is bad The current implementation has some drawbacks. For instance, when encountering other unsupported objects, the error looks like this: ERROR: cannot get tuple-level statistics for relation "x" DETAIL: This operation is not supported for foreign tables. However, for sequences, the message should explicitly state that "This operation is not supported for sequences." Currently, we're deducing that the heap access method (AM) is for relkind='r', so the message "only heap AM is supported" implies that only relkind='r' are supported. This prompted my thoughts on the matter. Moreover, if you refer to the code in pgstattuple.c <https://github.com/postgres/postgres/blob/master/contrib/pgstattuple/pgstattuple.c#L255-L256> , you'll notice that sequences appear to be explicitly allowed in pgstattuple, but it results in an error encountered here - https://github.com/postgres/postgres/blob/master/contrib/pgstattuple/pgstattuple.c#L326-L329 Therefore, I believe a small refactoring is needed to make the code cleaner and more consistent. > IMHO it would be good to establish some level of consistency here. Agree. Let me know your thoughts. Regards Ayush Vatsa AWS
