Re: pg_stat_statements query normalization

From: Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com>
To: Sameer Thakur <samthakur74(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: pg_stat_statements query normalization
Date: 2013-06-17 07:04:23
Message-ID: CAEYLb_V-=jBFgnTpy_LstoU6U8hiJ23uec-8GLp_nSiJG2SJOw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Sun, Jun 16, 2013 at 11:58 PM, Sameer Thakur <samthakur74(at)gmail(dot)com> wrote:
> Consider query
> SELECT * FROM pgbench_branches LEFT JOIN pgbench_tellers ON
> pgbench_tellers.bid= pgbench_branches.bid WHERE pgbench_branches.bID=5
>
> Does this mean that all queries with just the constant changing are
> normalized
>
> pgbench_branches.bID=10,pgbench_branches.bID=15
>
> Or are queries where conditions changed included as well?

Why don't you play around with it and see for yourself? In general,
queries differing only in the values of constants are considered
equivalent by the fingerprinting. pg_stat_statements usefully ignores
differences in whitespace and equivalent syntaxes, by virtue of the
fact that ultimately the post-parse analysis tree is fingerprinted.
You might say that pg_stat_statements leverages the normalization
capabilities of the core system by working off this later
representation (essentially, the internal representation that the
rewriter stage processes).

--
Regards,
Peter Geoghegan

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Josh Berkus 2013-06-18 19:07:21 Re: 9.2.2 - semop hanging
Previous Message Sameer Thakur 2013-06-17 06:58:15 pg_stat_statements query normalization