Re: Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

From: Lukas Fittl <lukas(at)fittl(dot)com>
To: Peter Geoghegan <pg(at)heroku(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)
Date: 2015-11-25 08:13:11
Message-ID: CAP53PkxjvRhR7JrKaqM6YouqCMGR4s=VqSXC8xZtPmgJvAuj-A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 23, 2015 at 11:53 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:

> One specific justification he gave for not using pg_stat_statements was:
>
> "Doesn’t merge bind vars in IN()" (See slide #11)
>
> I wonder:
>
> * How do other people feel about this? Personally, I've seen enough
> problems of this kind in the field that "slippery slope" arguments
> against this don't seem very compelling.
>

As someone who runs a little monitoring service thats solely based on
pg_stat_statements data, ignoring IN list length would certainly be a good
change.

We currently do this in post-processing, together with other data cleanup
(e.g. ignoring the length of a VALUES list in an INSERT statement).

Given the fact that pgss data is normalized & you don't know which plan was
chosen, I don't think distinguishing based on the length of the list helps
anyone really.

I see pg_stat_statements as a high-level overview of which queries have
run, and which ones you might want to look into closer using e.g.
auto_explain.

Best,
Lukas

--
Lukas Fittl

Skype: lfittl
Phone: +1 415 321 0630

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2015-11-25 08:18:18 Re: pg_hba_lookup function to get all matching pg_hba.conf entries
Previous Message Peter Geoghegan 2015-11-25 07:48:25 Re: Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)