From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Add n_tup_newpage_upd to pg_stat table views |
Date: | 2023-01-30 18:45:28 |
Message-ID: | 20230130184528.k4m62insd6hciwyt@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2023-01-30 18:46:07 | Re: Non-superuser subscription owners |
Previous Message | Corey Huinker | 2023-01-30 18:40:15 | Re: Add n_tup_newpage_upd to pg_stat table views |