On 2018-11-29 16:58:05 +0100, Dmitry Dolgov wrote:
> > On Mon, Oct 1, 2018 at 8:30 AM Michael Paquier wrote:
> >
> > On Tue, Apr 17, 2018 at 05:58:44PM +0200, Vik Fearing wrote:
> > > I think I handle that well enough with permission checking, but I'm open
> > > to more debate on it.
> >
> > The r
> On Mon, Oct 1, 2018 at 8:30 AM Michael Paquier wrote:
>
> On Tue, Apr 17, 2018 at 05:58:44PM +0200, Vik Fearing wrote:
> > I think I handle that well enough with permission checking, but I'm open
> > to more debate on it.
>
> The recent version bump in pg_stat_statements (Sorry my fault!) is
> c
On Tue, Apr 17, 2018 at 05:58:44PM +0200, Vik Fearing wrote:
> I think I handle that well enough with permission checking, but I'm open
> to more debate on it.
The recent version bump in pg_stat_statements (Sorry my fault!) is
causing this patch to not apply anymore. I have moved it to next CF
wi
On Thu, Jun 21, 2018 at 12:28:01PM +0200, Daniel Gustafsson wrote:
> I happened to notice that this patch was moved from Returned with Feedback to
> Needs Review after the CF closed, which means it’s now sitting open in a
> closed
> CF. The intended flow after RWF is that the patch is resubmitted
> On 17 Apr 2018, at 17:58, Vik Fearing wrote:
> Thanks! Attached is a patch addressing your concerns.
I happened to notice that this patch was moved from Returned with Feedback to
Needs Review after the CF closed, which means it’s now sitting open in a closed
CF. The intended flow after RWF i
On 03/10/2018 03:02 PM, Tomas Vondra wrote:
> Hi,
>
> I've looked at this patch today. I like the idea / intent in general, as
> it helps with some investigation tasks. That being said, I have a couple
> of questions/comments based on read through the patch:
Thanks! Attached is a patch addressin
On 3/21/18 1:31 PM, David Steele wrote:
>
> On 3/10/18 9:02 AM, Tomas Vondra wrote:
>>
>> I've looked at this patch today. I like the idea / intent in general, as
>> it helps with some investigation tasks. That being said, I have a couple
>> of questions/comments based on read through the patch:
>
+1
If pgss had a PlanId column (just after QueryId), that would be wonderfull
;o)
Question: Is there a simple way to "un-normalize" the query (I mean rebuild
the original query as it was before normalization) ?
Regards
PAscal
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers
Hi Vik,
On 3/10/18 9:02 AM, Tomas Vondra wrote:
>
> I've looked at this patch today. I like the idea / intent in general, as
> it helps with some investigation tasks. That being said, I have a couple
> of questions/comments based on read through the patch:
It looks like there are some privacy co
I've often wanted something similar. But I've struggled to come up
with a good way to decide which parameters to keep. And as someone
mentioned, there's the question of how to deal with very large
constants.
The other day I was poking around with pg_stat_statements and jsonlog
and I thought of ano
Hi,
I've looked at this patch today. I like the idea / intent in general, as
it helps with some investigation tasks. That being said, I have a couple
of questions/comments based on read through the patch:
1) I see you've renamed the .sql script from 1.4 to 1.6. I thought we've
abandoned that app
On 03/01/2018 07:26 PM, Andres Freund wrote:
> Hm. Isn't this going to blow up the size of the file in cases with a
> number of parameters quite considerably, a file limit notwithstanding?
> Wonder if the size limit wouldn't have to be across all params.
It is across all params (per queryid).
--
Hi,
On 2017-12-31 12:34:17 +0100, Vik Fearing wrote:
> Often when looking through pg_stat_statements, it would be nice to have
> some sample values for the constants and parameters. This patch
> implements that by taking the values from the first execution of the
> normalized query.
>
> To keep
Hi Vik,
this is my review of your patch. I hope I've ticked all the necessary
boxes.
Submission review:
Patch has context, applies cleanly, make and make check run
successfully, patch contains tests for the added functionality.
The patch doesn't seem to contain any documentation regarding the ne
Often when looking through pg_stat_statements, it would be nice to have
some sample values for the constants and parameters. This patch
implements that by taking the values from the first execution of the
normalized query.
To keep things reasonable, there is a limit on how big the parameters
can
15 matches
Mail list logo
