Re: Hash-based MCV matching for large IN-lists

From: "Matheus Alcantara" <matheusssilv97(at)gmail(dot)com>
To: "Ilia Evdokimov" <ilya(dot)evdokimov(at)tantorlabs(dot)com>, "Tatsuya Kawata" <kawatatatsuya0913(at)gmail(dot)com>, "David Geier" <geidav(dot)pg(at)gmail(dot)com>
Cc: "Chengpeng Yan" <chengpeng_yan(at)outlook(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Hash-based MCV matching for large IN-lists
Date: 2026-02-24 19:32:15
Message-ID: DGNFXVTPKNX4.2D61JYJY21QJ1@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi, thanks for working on this!

On Wed Feb 18, 2026 at 9:48 AM -03, Ilia Evdokimov wrote:
> I've fixed all the comments raised above and updated the v5 patch.
>

Here are some comments regarding v5 patch:

On scalararraysel() we have:

+ ReleaseVariableStats(vardata);
+
+ if (s1 >= 0.0)
+ return s1;

I'm wondering if we also should call ReleaseVariableStats() on the early
return?

+ if (!useOr && elem_nulls[i])
+ {
+ pfree(elem_values);
+ pfree(elem_nulls);
+ pfree(elem_const);
+
+ return (Selectivity) 0.0;
+ }

------------------

On scalararray_mcv_hash_match() free_attstatsslot() is called only on
if (have_mcvs && OidIsValid(hashLeft) && OidIsValid(hashRight)),
perhaps it should be moved outside the if condition?

+ if (have_mcvs && OidIsValid(hashLeft) && OidIsValid(hashRight))
+ {
+ ...

+ MCVHashTable_destroy(hashTable);
+ free_attstatsslot(&sslot);
+ }
+
+ return selec;

------------------

typo: "all elements are const"

+ * array is NULL if all elemnets is const.

------------------

It's worth adding on scalararray_mcv_hash_match() an early return when
num_elems == 0? I imagine that this can happens, e.g "WHERE a =
ANY(array[]::int[]);". In this case the function should still execute
completely?

--
Matheus Alcantara
EDB: https://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mihail Nikalayeu 2026-02-24 19:48:00 Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements
Previous Message Jacob Champion 2026-02-24 18:58:30 Re: pgsql: libpq: Grease the protocol by default