Re: Improve handling of pg_stat_statements handling of bind "IN" variables - Mailing list pgsql-hackers

From Pavel Trukhanov
Subject Re: Improve handling of pg_stat_statements handling of bind "IN" variables
Date
Msg-id CAF42k=LHMr-ig4ydjr6V1_MKAN58VprSmf=d1UdzZp56HH_J5Q@mail.gmail.com
Whole thread Raw
In response to Re: Improve handling of pg_stat_statements handling of bind "IN" variables  (Dmitry Dolgov <9erthalion6@gmail.com>)
Responses Re: Improve handling of pg_stat_statements handling of bind "IN" variables
List pgsql-hackers
Thanks for your reply

> If I understand correctly, "IN (...)" is reprecented by A_Expr with kind
> AEXPR_IN, and only in transformAExprIn converted to ArrayExpr if possible.
That seems to be correct, yes, thank you.

> So probably it doesn't makes sense to introduce another one.
Though I might've used wrong words to describe my holdback here, what
I meant is that I'll need to create new node type (in primnodes.h?)
for IN-list, that will allow to differentiate it from direct "ARRAY"
usage.
This will require changes to parse_expr.c, execExpr.c, etc, which
seems to be overkill for such issue IMO, hence the question.
Please advise.

> > For example "SELECT ARRAY[1, 2, a] FROM table" and "SELECT ARRAY[b]
> > FROM table" might end up in the same pgss entry.
>
> What are a, b here, parameters?

Here a and b are table columns.
I couldn't come up with other examples of ARRAY usage, would
appreciate any suggestions.


> > 3 Tests in pgss.sql/out and Vars
> > I would like someone to point me in a direction of how could I
> > implement a test that will query
> > "SELECT * FROM test WHERE a IN ($1, $2, $3, ...)" with params, not
> > consts
>
> Wouldn't a prepared statement work? It will create an ArrayExpr with Params
> inside.

Thanks for the tip. It seems to work, at least it looks like it.



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
Next
From: Jesper Pedersen
Date:
Subject: Re: Index Skip Scan