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

From: John Naylor <johncnaylorls(at)gmail(dot)com>
To: Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com>
Cc: Chengpeng Yan <chengpeng_yan(at)outlook(dot)com>, Tatsuya Kawata <kawatatatsuya0913(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] ANALYZE: hash-accelerate MCV tracking for equality-only types
Date: 2026-05-04 02:10:16
Message-ID: CANWCAZYBjANakZjyc_Gk0Myc13rC3XKgSV3zk+m1Jds1mEs0cw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 26, 2026 at 6:46 PM Ilia Evdokimov
<ilya(dot)evdokimov(at)tantorlabs(dot)com> wrote:
> While reviewing the patch more closely, I noticed
> that compute_distinct_stats() is only used for types where we have =, !=
> but not <. In practice, most common scalar types go through
> compute_scalar_stats() instead.
>
> That makes me wonder how often this optimization would actually trigger
> in real workloads. Since compute_scalar_stats() is the more common path,
> there's chance that the hash-table based improvement in
> compute_distinct_stats() may not provide a noticeable overall benefit.

Coming back to this point, in any installation, the common path is
going to vastly outnumber the rare path, so this patch is optimizing
the wrong thing.

--
John Naylor
Amazon Web Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2026-05-04 02:23:47 Adjust pg_stat_get_lock() prorows to match lock types
Previous Message Bharath Rupireddy 2026-05-04 02:00:00 Report index currently being vacuumed in pg_stat_progress_vacuum