On Sat, Aug 19, 2023 at 01:47:48PM +0900, Michael Paquier wrote:
> On Fri, Aug 18, 2023 at 11:31:03AM +0100, Dagfinn Ilmari Mannsåker wrote:
>> I don't have a particularly strong opinion on whether we should
>> distinguish DEALLOCATE ALL from DEALLOCATE (call it +0.5), but
>
> The difference look
On Fri, Aug 18, 2023 at 11:31:03AM +0100, Dagfinn Ilmari Mannsåker wrote:
> I don't have a particularly strong opinion on whether we should
> distinguish DEALLOCATE ALL from DEALLOCATE (call it +0.5), but
The difference looks important to me, especially for monitoring.
And pgbouncer may also use
Michael Paquier writes:
> On Tue, Aug 15, 2023 at 08:49:37AM +0900, Michael Paquier wrote:
>> Hmm. One issue with the patch is that we finish by considering
>> DEALLOCATE ALL and DEALLOCATE $1 as the same things, compiling the
>> same query IDs. The difference is made in the Nodes by assigning
On Tue, Aug 15, 2023 at 08:49:37AM +0900, Michael Paquier wrote:
> Hmm. One issue with the patch is that we finish by considering
> DEALLOCATE ALL and DEALLOCATE $1 as the same things, compiling the
> same query IDs. The difference is made in the Nodes by assigning NULL
> to the name but we would
On Mon, Aug 14, 2023 at 12:11:13PM +0100, Dagfinn Ilmari Mannsåker wrote:
> As far as I could tell the only thing missing was removing
> DeallocateStmt from the list of unhandled utility statement types (and
> updating comments to match). Updated patch attached.
Hmm. One issue with the patch is
Michael Paquier writes:
> On Sun, Aug 13, 2023 at 02:48:22PM +0800, Julien Rouhaud wrote:
>> On Sun, Aug 13, 2023 at 03:25:33PM +0900, Michael Paquier wrote:
>>> Perhaps not as much, actually, because I was just reminded that
>>> DEALLOCATE is something that pg_stat_statements ignores. So this
>
On Sun, Aug 13, 2023 at 02:48:22PM +0800, Julien Rouhaud wrote:
> On Sun, Aug 13, 2023 at 03:25:33PM +0900, Michael Paquier wrote:
>> Perhaps not as much, actually, because I was just reminded that
>> DEALLOCATE is something that pg_stat_statements ignores. So this
>> makes harder the introduction
On Sun, Aug 13, 2023 at 03:25:33PM +0900, Michael Paquier wrote:
> On Tue, Aug 01, 2023 at 10:46:58AM +0800, Julien Rouhaud wrote:
> >
> > Agreed, it should be as trivial to implement as for the 2pc commands :)
>
> Perhaps not as much, actually, because I was just reminded that
> DEALLOCATE is some
On Tue, Aug 01, 2023 at 10:46:58AM +0800, Julien Rouhaud wrote:
> On Tue, Aug 01, 2023 at 11:37:49AM +0900, Michael Paquier wrote:
>> On Tue, Aug 01, 2023 at 10:22:09AM +0800, Julien Rouhaud wrote:
>>> Looking at the rest of the ignored patterns, the only remaining one would be
>>> DEALLOCATE, whic
On Tue, Aug 01, 2023 at 11:37:49AM +0900, Michael Paquier wrote:
> On Tue, Aug 01, 2023 at 10:22:09AM +0800, Julien Rouhaud wrote:
> > Looking at the rest of the ignored patterns, the only remaining one would be
> > DEALLOCATE, which AFAICS doesn't have a query_jumble_ignore tag for now.
>
> This o
On Tue, Aug 01, 2023 at 10:22:09AM +0800, Julien Rouhaud wrote:
> Looking at the rest of the ignored patterns, the only remaining one would be
> DEALLOCATE, which AFAICS doesn't have a query_jumble_ignore tag for now.
This one seems to be simple as well with a location field, looking
quickly at it
On Tue, Aug 01, 2023 at 11:00:32AM +0900, Michael Paquier wrote:
> On Tue, Aug 01, 2023 at 09:28:08AM +0800, Julien Rouhaud wrote:
>
> > FTR we had to entirely ignore all those statements in powa years ago to try
> > to
> > make the tool usable in such case for some users who where using 2pc, it
On Tue, Aug 01, 2023 at 09:28:08AM +0800, Julien Rouhaud wrote:
> Having an application relying on 2pc leads to pg_stat_statements being
> virtually unusable on the whole instance, so +1 for the patch.
Cool, thanks for the feedback!
> FTR we had to entirely ignore all those statements in powa yea
Hi,
On Tue, Aug 01, 2023 at 09:38:14AM +0900, Michael Paquier wrote:
>
> 31de7e6 has silenced savepoint names in the query jumbling, and
> something similar can be done for 2PC transactions once the GID is
> ignored in TransactionStmt. This leads to the following grouping in
> pg_stat_statements,
Hi all,
31de7e6 has silenced savepoint names in the query jumbling, and
something similar can be done for 2PC transactions once the GID is
ignored in TransactionStmt. This leads to the following grouping in
pg_stat_statements, for instance, which is something that matters with
workloads that heav
15 matches
Mail list logo
