| From: | Damil Shahzad <shahzaddamil(at)gmail(dot)com> |
|---|---|
| To: | ZizhuanLiu X-MAN <44973863(at)qq(dot)com> |
| Cc: | Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Fix var_eq_const: sum selectivity of all matching MCV entries instead of stopping at first match |
| Date: | 2026-08-06 07:59:27 |
| Message-ID: | CALRDUFo=5VDzY66O1oHUQyRjO5_KaP5p8so5LBPqSVJtL_bbxw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi ZizhuanLiu,
Thanks for sending v2. I tested it using your test_mcv setup and the
case_insensitive example I tried before.
On the case you are targeting, deterministic column and non deterministic
expression in the query, it looks good to me. Without the patch, c1 = 'a-1'
COLLATE "case_insensitive" estimated 2 rows but actually returned 4. With
v2 it estimated 4 and returned 4. Same kind of fix on my other table, a =
'b' COLLATE "case_insensitive" went from estimated 10 to estimated 19, and
actual was 19.
The normal equality cases I checked still looked the same as before, things
like c1 = 'a-1', a = 'B', and a = 'b'.
For the other cases in your spreadsheet, v2 seemed to keep the old first
match behavior, which matches what you described. I did still see c2 =
'A-1' COLLATE "default" estimate 1 vs actual 2, but I think that is the out
of scope case you already noted.
Overall I think v2 is a much better direction than v1. I don't have extra
test cases to add beyond what is already in your spreadsheet.
Thanks,
Damil Shahzad
On Thu, 6 Aug 2026 at 12:25, ZizhuanLiu X-MAN <44973863(at)qq(dot)com> wrote:
> Original
> >From: ZizhuanLiu X-MAN <44973863(at)qq(dot)com>
> >Date: 2026-08-05 18:44
> >To: Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com>, Damil Shahzad <
> shahzaddamil(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> >Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
> >Subject: Re: Fix var_eq_const: sum selectivity of all matching MCV
> entries instead of stopping at first match
> >>From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> >>Date: 2026-07-30 21:39
> >>To: ZizhuanLiu X-MAN <44973863(at)qq(dot)com>
> >>Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
> >
> >
> >>Subject: Re: Fix var_eq_const: sum selectivity of all matching MCV
> entries instead of stopping at first match
> >
> >>I think you need a far stronger
> >>argument for changing the existing tradeoff than "I believe".
> >Although I have made efforts to implement it, there is still
> >no satisfactory and acceptable solution available at present.
> >
> >>That would double the function's runtime on average, without changing
> >>the results at all in most cases (it could only be different if the
> >>given operator has different semantics from the equality operator used
> >>while building the statistics list).
> >So I agree with Tom’s reasoning.
> >
> >regards,
> >--
> >ZizhuanLiu (X-MAN)
> >44973863(at)qq(dot)com
>
> Hi, Ilia
> After further consideration, based on the definition of the
> AttStatsSlot
> data structure and the functional logic of get_attstatsslot(),
> sslot.nvalues
> and sslot.nnumbers are two members that are not guaranteed to be
> symmetric or equal. Therefore, for the logic related to sumcommon,
> I suggest taking a conservative approach and leaving it untouched for this
> patch.
>
>
> Original
> >From: ZizhuanLiu X-MAN <44973863(at)qq(dot)com>
> >Date: 2026-08-05 18:31
> >To: Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com>, Damil Shahzad <
> shahzaddamil(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> >Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
> >Subject: Re: Fix var_eq_const: sum selectivity of all matching MCV
> entries instead of stopping at first match
> >Hi all,
> > Upon further careful analysis,I have found that that full MCV
> scanning is
> >only justified and beneficial under the following condition:
> >the column has a deterministic collation, and the expression uses a
> >non-deterministic collation.
>
> Hi Damil, all,
> The patch currently implements only this scenario, and addresses only
> the test cases listed in the attached spreadsheet:
> ```SQL
> explain analyze select * from test_mcv where c1 = 'a-0' collate
> ""case_insensitive""; --Some adjustments are needed, yet this idea is
> feasible.
> explain analyze select * from test_mcv where c1 = 'a-1' collate
> ""case_insensitive""; --Some adjustments are needed, yet this idea is
> feasible.
> explain analyze select * from test_mcv where c1 = 'a-2' collate
> ""case_insensitive""; --Some adjustments are needed, yet this idea is
> feasible.
>
> I welcome additional comprehensive test cases and suggestions for
> improvements.
> We will add and refine regression tests once testing and feedback have
> stabilized.
>
> regards,
> --
> ZizhuanLiu (X-MAN)
> 44973863(at)qq(dot)com
>
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bharath Rupireddy | 2026-08-06 08:02:44 | Re: [PATCH] Release replication slot on error in SQL-callable slot functions |
| Previous Message | John Naylor | 2026-08-06 07:55:24 | Re: [PATCH] Use ssup_datum_*_cmp for int2, oid, and oid8 sort support |