Message-ID: <6ad08c0c-2c03-4b30-b5a7-dc486aa29c52@dalibo.com>
Date: Mon, 22 Sep 2025 15:37:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Indexes on expressions with multiple columns and operators
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "pgsql-performance@lists.postgresql.org"
 <pgsql-performance@lists.postgresql.org>,
 Jehan-Guillaume de Rorthais <jgdr@dalibo.com>,
 Christophe Courtois <christophe.courtois@dalibo.com>,
 Laurenz Albe <laurenz.albe@cybertec.at>
References: <a8b99dce-1bfb-4d97-af73-54a32b85c916@dalibo.com>
 <1507576.1758120083@sss.pgh.pa.us>
 <62133334-b844-4d0b-b248-1a8446757e5f@dalibo.com>
 <1916727.1758209549@sss.pgh.pa.us> <1972974.1758213639@sss.pgh.pa.us>
 <76fbd9ef-1fbb-49f0-bc8b-844462b18d1d@dalibo.com>
 <2432873.1758387110@sss.pgh.pa.us>
From: =?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Yhuel?= <frederic.yhuel@dalibo.com>
Content-Language: fr, en-US
Autocrypt: addr=frederic.yhuel@dalibo.com; keydata=
 xjMEXn3bgxYJKwYBBAHaRw8BAQdA6tX5FT/n5ztMWIoBdl6k5avvu65fv6ryfVzIx/aH3V3N
 JEYuIFlodWVsIDxmcmVkZXJpYy55aHVlbEBkYWxpYm8uY29tPsKWBBMWCAA+FiEEi7OTyf6H
 ePS+C6n11XGWhN8zGNUFAmZDVJ8CGwMFCQtfi90FCwkIBwIGFQoJCAsCBBYCAwECHgECF4AA
 CgkQ1XGWhN8zGNV65gEA6o+UrebFjn2CIAOYwP3CiiJugiM5TMH9yJyehQua5ZoA/2ChxiVn
 8OUaAw/ErxJmQi1mSN0tNZBL/KhkUPBDUDQNzjgEXn3bgxIKKwYBBAGXVQEFAQEHQCuh5cLQ
 AtEBXHa2Fmtp0kduBu7msM7qO/gaEcdjFUdiAwEIB8J+BBgWCAAmAhsMFiEEi7OTyf6HePS+
 C6n11XGWhN8zGNUFAmZDVJ8FCQtfi90ACgkQ1XGWhN8zGNWOOAEArSqePBqfd4Kx4ulACaWO
 6fM+XSDfUlBAQXx9rU6DR4MBALwozl9g91tRysim6lKxggvBfp/PvbpTZNrxYLWB2fYP
In-Reply-To: <2432873.1758387110@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/6ad08c0c-2c03-4b30-b5a7-dc486aa29c52%40dalibo.com>
Precedence: bulk


On 9/20/25 18:51, Tom Lane wrote:
> I concluded that maybe I was overthinking this part.  We only really
> need to check the rowcount estimate, since the indexscan cost estimate
> is already okay.  And stats_ext.sql seems to have gotten away with
> assuming that rowcount estimates are reliably reproducible on
> not-too-large tables.  This bug affects use of extended statistics
> too, so a test using those is good enough to show it's fixed; we don't
> really need to use an expression index for the purpose.  So, I added a
> test case in stats_ext.sql and pushed it.

OK, great! Thanks for the detailed explanation.

Regarding extended statistics, it's unfortunate that they cannot be used 
in this case. Multivariate MCV statistics work as long as the number of 
rows in the table is reasonably small (100K) and the STATISTICS value 
for a column is high enough (it doesn't matter which column, because 
only the sample size matters).

I wonder if this is an argument in favour of decoupling the sample size 
and the precision of the statistics. Here, we basically want the sample 
size to be as big as the table in order to include the few (NULL, 
WARNING) values.

Or maybe we need a different kind of extended statistics?