Re: pg_stat_statements and "IN" conditions - Mailing list pgsql-hackers

From Dmitry Dolgov
Subject Re: pg_stat_statements and "IN" conditions
Date
Msg-id 20230205195600.e3bhwszzm5kdyyxl@erthalion.local
Whole thread Raw
In response to Re: pg_stat_statements and "IN" conditions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re:pg_stat_statements and "IN" conditions
List pgsql-hackers
> On Sun, Feb 05, 2023 at 11:02:32AM -0500, Tom Lane wrote:
> Dmitry Dolgov <9erthalion6@gmail.com> writes:
> > I'm thinking about this in the following way: the core jumbling logic is
> > responsible for deriving locations based on the input expressions; in
> > the case of merging we produce less locations; pgss have to represent
> > the result only using locations and has to be able to differentiate
> > simple locations and locations after merging.
>
> Uh ... why?  ISTM you're just going to elide all inside the IN,
> so why do you need more than a start and stop position?

Exactly, start and stop positions. But if there would be no information
that merging was applied, the following queries will look the same after
jumbling, right?

    -- input query
    SELECT * FROM test_merge WHERE id IN (1, 2);
    -- jumbling result, two LocationLen, for values 1 and 2
    SELECT * FROM test_merge WHERE id IN ($1, $2);

    -- input query
    SELECT * FROM test_merge WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
    -- jumbling result, two LocationLen after merging, for values 1 and 10
    SELECT * FROM test_merge WHERE id IN (...);
    -- without remembering about merging the result would be
    SELECT * FROM test_merge WHERE id IN ($1, $2);



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [PATCH] Compression dictionaries for JSONB
Next
From: Tom Lane
Date:
Subject: Re: First draft of back-branch release notes is done