Re: Add n_tup_newpage_upd to pg_stat table views - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Add n_tup_newpage_upd to pg_stat table views
Date
Msg-id 20230130184528.k4m62insd6hciwyt@awork3.anarazel.de
Whole thread Raw
In response to Re: Add n_tup_newpage_upd to pg_stat table views  (Corey Huinker <corey.huinker@gmail.com>)
List pgsql-hackers
Hi,

On 2023-01-30 13:40:15 -0500, Corey Huinker wrote:
> I must be missing something, I only see the check for running out of space,
> not the check for exhausting line pointers. I agree dividing them would be
> interesting.

See PageGetHeapFreeSpace(), particularly the header comment and the
MaxHeapTuplesPerPage check.


> > Similarly, it's a bit sad that we can't distinguish between the number of
> > potential-HOT out-of-page updates and the other out-of-page updates. But
> > that'd mean even more counters.
>
> I wondered that too, but the combinations of "would have been HOT but not
> no space" and "key update suggested not-HOT but it was id=id so today's
> your lucky HOT" combinations started to get away from me.

Not sure I follow the second part. Are you just worried about explaining when
a HOT update is possible?


> I wondered if there was interest in knowing if the tuple had to get
> TOASTed, and further wondered if we would be interested in the number of
> updates that had to wait on a lock. Again, more counters.

Those seem a lot less actionable / related to the topic at hand to me.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Corey Huinker
Date:
Subject: Re: Add n_tup_newpage_upd to pg_stat table views
Next
From: Mark Dilger
Date:
Subject: Re: Non-superuser subscription owners