On 15/3/26 18:18, Andrey Borodin wrote:
On 13 Mar 2026, at 18:04, Alena Rybakina <[email protected]> wrote:
I've decided to take a look into v31.
Overall idea of tracking VM dynamics seems good to me.
But the column naming for rev_all_visible_pages and rev_all_frozen_pages
seems strange to me. I've skimmed the thread but could not figure out what
"rev_" stands for. Revisions? Revolutions? Reviews?
I suppose 'revert' is the exact term here. Someone decided to set the
flag, and we reverted his decision. Does this make sense to you? Anyway,
I always leave it in the natives' (and committers') hands.
Is there a reason why you break "SELECT * FROM pg_stat_all_tables" for
an existing software? IMO even if we want these columns in this exact view
- they ought to be appended to the end of the column list.
Please specify what you mean by this 'break'?
The relational model has never guaranteed a specific order of columns
returned unless you specify their names explicitly as a list. I think it
is good if someone found a flaw in their application, depending on the
wildcard order. So, I organised the elements according to their logical
order.
What's more? If you check the history of this VIEW, you will find that
it has always been updated in logical order. Please explain your point
if I misunderstood it.
Some nits about the code.
I doubt if we need a test for these parameters - they reflect the
physical structure of the storage and might be unstable. But anyway, it
should be better to live in isolation tests, as similar statistics.
Thanks for your efforts!
--
regards, Andrei Lepikhov,
pgEdge
