Re: pg_stat_statements and "IN" conditions

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
Cc: Julien Rouhaud <rjuju123(at)gmail(dot)com>, Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, Sergei Kornilov <sk(at)zsrv(dot)org>, yasuo(dot)honda(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, smithpb2250(at)gmail(dot)com, vignesh21(at)gmail(dot)com, michael(at)paquier(dot)xyz, nathandbossart(at)gmail(dot)com, stark(dot)cfm(at)gmail(dot)com, geidav(dot)pg(at)gmail(dot)com, marcos(at)f10(dot)com(dot)br, robertmhaas(at)gmail(dot)com, david(at)pgmasters(dot)net, pgsql-hackers(at)postgresql(dot)org, pavel(dot)trukhanov(at)gmail(dot)com, Sutou Kouhei <kou(at)clear-code(dot)com>
Subject: Re: pg_stat_statements and "IN" conditions
Date: 2025-02-17 19:50:00
Message-ID: CAA5RZ0sO9yUwbXaZVUCYSDsMvOowt_S96ja09-K=CZC+j+y91w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> This test was to catch a crash that was happening in older version of
> the patch, so it doesn't have to verify the actual pgss entry.

It seems odd to keep this test because of crash behavior experienced
in a previous version of the patch. if the crash reason was understood
and resolved, why keep it?

> > 2/ Looking at IsMergeableConst, I am not sure why we care about
> > things like function volatility, implicit cast or funcid > FirstGenbkiObjectId?
>
> Function volatility is important to establish how constant is the
> result, for now we would like to exclude not immutable functions. The
> implicit cast and builtin check are there to limit squashing and exclude
> explicit or user-created functions (the second is probably an overkill,
> but this could be gradually relatex later). Or are you not sure about
> something different?

My thoughts are when dealing with FuncExpr, if the first arg in the list of
func->args is a Const, shouldn't that be enough to tell us that we have
a mergeable value. If it's not a Const, it may be another FuncExpr, so
that tells us we don't have a mergeable list. Why would this not be enough?

See the attached 0001-experiement-on-top-of-v27.patch
which applies on top of v27 and produces the results like below.

postgres=# explain verbose select from test_merge where id in (1, 2,
3, 4, 5, 6::bigint);
QUERY PLAN
-------------------------------------------------------------------
Seq Scan on public.test_merge (cost=0.00..49.55 rows=68 width=0)
Filter: (test_merge.id = ANY ('{1,2,3,4,5,6}'::bigint[]))
Query Identifier: 9190277587190463639
(3 rows)

postgres=# explain verbose select from test_merge where id in (1, 2,
3, 4, 5, 6::bigint, 7);
QUERY PLAN
-------------------------------------------------------------------
Seq Scan on public.test_merge (cost=0.00..52.38 rows=79 width=0)
Filter: (test_merge.id = ANY ('{1,2,3,4,5,6,7}'::bigint[]))
Query Identifier: 9190277587190463639
(3 rows)

postgres=# explain verbose select from test_merge where id in (1, 2,
3, 4, 5, 6::bigint, 7, testf5(1));

QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------------
Seq Scan on public.test_merge (cost=0.00..625.85 rows=90 width=0)
Filter: (test_merge.id = ANY (ARRAY['1'::bigint, '2'::bigint,
'3'::bigint, '4'::bigint, '5'::bigint, '6'::bigint, '7'::bigint,
(testf5(1))::bigint]))
Query Identifier: 4874022288496461916
(3 rows)

--

Sami

Attachment Content-Type Size
0001-experiement-on-top-of-v27.patch application/octet-stream 2.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Burd, Greg 2025-02-17 19:53:47 Re: Expanding HOT updates for expression and partial indexes
Previous Message Jeff Davis 2025-02-17 19:46:43 Re: Update Unicode data to Unicode 16.0.0