Re: Vacuum statistics - Mailing list pgsql-hackers

From Andrei Lepikhov
Subject Re: Vacuum statistics
Date
Msg-id cd323289-5ac7-42e4-9fec-b87cf8fdb40a@gmail.com
Whole thread Raw
In response to Re: Vacuum statistics  (Andrey Borodin <x4mmm@yandex-team.ru>)
Responses Re: Vacuum statistics
List pgsql-hackers
On 15/3/26 18:18, Andrey Borodin wrote:
> 
> 
>> On 13 Mar 2026, at 18:04, Alena Rybakina <lena.ribackina@yandex.ru> 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



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Skipping schema changes in publication
Next
From: Amit Kapila
Date:
Subject: Re: Skipping schema changes in publication