Re: [PATCH] ANALYZE: hash-accelerate MCV tracking for equality-only types

From: Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com>
To: Chengpeng Yan <chengpeng_yan(at)Outlook(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, John Naylor <johncnaylorls(at)gmail(dot)com>
Subject: Re: [PATCH] ANALYZE: hash-accelerate MCV tracking for equality-only types
Date: 2026-01-29 21:54:15
Message-ID: 2e204485-8bf3-4ef4-add8-0563c536a537@tantorlabs.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 22.01.2026 12:40, Chengpeng Yan wrote:

> The v2 patch is attached.

I took a deeper look at the v2 patch. The hash-based lookup itself looks
correct, and when testing ANALYZE runtime with large
default_statistics_target values, the patch indeed provides a noticeable
speedup.

I have one small suggestion regarding the handling of firstcount1 and
c1_cursor in the 'match' path.

When we find a match in track[], we increment count and perform
bubble-up swaps to keep the array ordered by frequency. If the value
previously has count = 1, it is effectively leaving the singleton (count
= 1) region and becoming part of the count>1. Conceptually, this means
that the boundary between these two regions (firstcount1) should move
left by one.

Given that, it seems sufficient to update the boundary and then ensure
that c1_cursor still point inside the singleton region:

if (was_count1 && j < firstcount1)
    firstcount1--;
if (c1_cursor < firstcount1)
    c1_cursor = firstcount1;

This avoids reasoning about specific shifted subranges
(firstcount1..match_index). FIFO behavior is still preserved because
c1_cursor is only advanced when an eviction actually happens.

Let me know if I'm overlooking any corner cases.

--
Best regards.
Ilia Evdokimov,
Tantor Labs LLC,
https://tantorlabs.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2026-01-29 21:56:25 Re: Pasword expiration warning
Previous Message Andres Freund 2026-01-29 21:49:36 Re: Buffer locking is special (hints, checksums, AIO writes)