| From: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
|---|---|
| To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Vaibhav Jain <jainva(at)google(dot)com>, pg(at)bowt(dot)ie, andres(at)anarazel(dot)de |
| Subject: | Re: [BUG / PATCH] PG19: VACUUM misestimates reltuples (often 0) after on-access VM setting |
| Date: | 2026-11-13 07:08:06 |
| Message-ID: | CAN4CZFN5OkVm6hpEFJx0pfFh0kgVkBwpmpG70GbNmwOMOS=aBw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 13 Nov 2026, Melanie Plageman <melanieplageman(at)gmail(dot)com> wrote:
> So I did mean for a sentinel/unknown value to be returned here.
> However, it looks like the value should be 0 and not -1.
Sorry if that wasn't clear from my email, I didn't question the value
changing, only the part where the -1 is visible to users, as that
seems like a preexisting bug that now got one more case.
> So, to clamp it, we should save the return value of
> vac_estimate_reltuples() in a double and clamp it to 0 before
> assigning to stat->tuple_count.
Yes, either that or tuple_count should be signed, but the current way
doesn't seem to be good.
One more nit for the original v2-0001:
+ * value when at most one page was scanned. When the relation size has
+ * changed, use the old density to account for the added or removed pages
+ * instead of preserving a stale tuple count.
*
* (Note: we might be returning -1 here.)
*/
That note is now stale, with the condition moved before it.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrey Borodin | 2026-11-13 07:10:39 | Re: Add wait events for server logging destination writes |
| Previous Message | Heikki Linnakangas | 2026-11-13 06:46:59 | Re: SIGFPE handling |