On 07/20/2014 11:51 PM, Peter Geoghegan wrote:
On Sun, Jul 20, 2014 at 10:56 AM, Tom Lane wrote:
However, this is certainly a behavioral change. Perhaps squeeze it
into 9.4, but not the back braches?
+1
Ok, done. (We're a month closer to releasing 9.4 than we were when this
consensus was
On Sun, Jul 20, 2014 at 10:56 AM, Tom Lane wrote:
> However, this is certainly a behavioral change. Perhaps squeeze it
> into 9.4, but not the back braches?
+1
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
If you do not like my normalization hack (I do not like it much either:-), I
have suggested to add "&& !IsA(parsetree, DeallocateStmt)" to the condition
above, which would ignore DEALLOCATE as PREPARE and EXECUTE are currently
and rightfully ignored.
Well, EXECUTE isn't actually ignored, but
Andres Freund writes:
> On 2014-07-20 17:01:50 +0200, Fabien COELHO wrote:
>> If you do not like my normalization hack (I do not like it much either:-), I
>> have suggested to add "&& !IsA(parsetree, DeallocateStmt)" to the condition
>> above, which would ignore DEALLOCATE as PREPARE and EXECUTE a
[...]. If we do something we should go for the && !IsA(parsetree,
DeallocateStmt), not the normalization.
Ok.
The latter is pretty darn bogus.
Yep:-) I'm fine with ignoring DEALLOCATE altogether.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
On 2014-07-20 17:01:50 +0200, Fabien COELHO wrote:
>
> >That's because PREPARE isn't executed as it's own statement, but done on
> >the protocol level (which will need noticeably fewer messages). There's
> >no builtin logic to ignore actual PREPARE statements.
>
> ISTM that there is indeed a spec
That's because PREPARE isn't executed as it's own statement, but done on
the protocol level (which will need noticeably fewer messages). There's
no builtin logic to ignore actual PREPARE statements.
ISTM that there is indeed a special handling in function
pgss_ProcessUtility for PREPARE and E
That's because PREPARE isn't executed as it's own statement, but done on
the protocol level (which will need noticeably fewer messages). There's
no builtin logic to ignore actual PREPARE statements.
ISTM that there is indeed a special handling in function
pgss_ProcessUtility for PREPARE and E
On 2014-07-20 14:43:27 +0200, Fabien COELHO wrote:
> >a) Consider using the extended query protocol.
> >b) consider using unnamed prepared statements to reduce the number of
> > roundtrips
> >c) wonder why PREPARE/DEALLOCATE are so much more frequent than the
> > actualy query execution.
>
> (1)
Hello Andres,
Why isn't the driver using the extended query protocol? Sending
PREPARE/EXECUTE/DEALLOCATE wastes roundtrips...
It seems to me that it would be more helful if these similar entries where
aggregated together, that is if the query "normalization" could ignore the
name of the descr
On 2014-07-20 14:06, Andres Freund wrote:
On 2014-07-20 13:54:01 +0200, Andres Freund wrote:
On 2014-04-01 16:45:29 +0200, Fabien COELHO wrote:
I noticed that my pg_stat_statements is cluttered with hundreds of entries
like "DEALLOCATE dbdpg_p123456_7", occuring each only once.
Why isn't the
On 2014-07-20 13:54:01 +0200, Andres Freund wrote:
> Hi,
>
> On 2014-04-01 16:45:29 +0200, Fabien COELHO wrote:
> > I noticed that my pg_stat_statements is cluttered with hundreds of entries
> > like "DEALLOCATE dbdpg_p123456_7", occuring each only once.
>
> Why isn't the driver using the extende
Hi,
On 2014-04-01 16:45:29 +0200, Fabien COELHO wrote:
> I noticed that my pg_stat_statements is cluttered with hundreds of entries
> like "DEALLOCATE dbdpg_p123456_7", occuring each only once.
Why isn't the driver using the extended query protocol? Sending
PREPARE/EXECUTE/DEALLOCATE wastes round
Hello devs,
I noticed that my pg_stat_statements is cluttered with hundreds of entries
like "DEALLOCATE dbdpg_p123456_7", occuring each only once.
Here is a patch and sql test file to:
* normalize DEALLOCATE utility statements in pg_stat_statements
Some drivers such as DBD:Pg generate proce
I noticed that my pg_stat_statements is cluttered with hundreds of entries
like "DEALLOCATE dbdpg_p123456_7", occuring each only once.
It seems to me that it would be more helful if these similar entries where
aggregated together, that is if the query "normalization" could ignore the
name of
On 04/01/2014 10:45 AM, Fabien COELHO wrote:
Hello pgdevs,
I noticed that my pg_stat_statements is cluttered with hundreds of
entries like "DEALLOCATE dbdpg_p123456_7", occuring each only once.
It seems to me that it would be more helful if these similar entries
where aggregated together,
Hello pgdevs,
I noticed that my pg_stat_statements is cluttered with hundreds of entries
like "DEALLOCATE dbdpg_p123456_7", occuring each only once.
It seems to me that it would be more helful if these similar entries where
aggregated together, that is if the query "normalization" could igno
17 matches
Mail list logo
