queryId constant squashing does not support prepared statements - Mailing list pgsql-hackers

From Sami Imseih
Subject queryId constant squashing does not support prepared statements
Date
Msg-id CAA5RZ0tRXoPG2y6bMgBCWNDt0Tn=unRerbzYM=oW0syi1=C1OA@mail.gmail.com
Whole thread Raw
Responses Re: queryId constant squashing does not support prepared statements
List pgsql-hackers
62d712ec added the ability to squash constants from an IN LIST
for queryId computation purposes. This means that a similar
queryId will be generated for the same queries that only
different on the number of values in the IN-LIST.

The patch lacks the ability to apply this optimization to values
passed in as parameters ( i.e. parameter kind = PARAM_EXTERN )
which will be the case for SQL prepared statements and protocol level
prepared statements, i.e.

```
select from t where id in (1, 2, 3) \bind
```
or
```
prepare prp(int, int, int) as select from t where id in ($1, $2, $3);
```

Here is the current state,

```
postgres=# create table t (id int);
CREATE TABLE
postgres=# prepare prp(int, int, int) as select from t where id in ($1, $2, $3);
PREPARE
postgres=# execute prp(1, 2, 3);
postgres=# select from t where id in (1, 2, 3);
--
(0 rows)
postgres=# SELECT query, calls FROM pg_stat_statements ORDER BY query
COLLATE "C";
                                                   query
                                    | calls
-----------------------------------------------------------------------------------------------------------+-------
...
....
 select from t where id in ($1 /*, ... */)
                                    |     1
 select from t where id in ($1, $2, $3)
                                 |     1 <<- prepared statement
(6 rows)
```

but with the attached patch, the optimization applies.

```
 create table t (id int)
                                            |     1
 select from t where id in ($1 /*, ... */)
                                     |     2
(3 rows)
```

I think this is a pretty big gap as many of the common drivers such as JDBC,
which use extended query protocol, will not be able to take advantage of
the optimization in 18, which will be very disappointing.

Thoughts?

Sami Imseih
Amazon Web Services (AWS)

Attachment

pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Prevent an error on attaching/creating a DSM/DSA from an interrupt handler.
Next
From: Robert Haas
Date:
Subject: Re: pgsql: Add function to get memory context stats for processes