On Sun, Nov 15, 2015 at 1:34 AM, Tom Lane wrote:
> Michael Paquier writes:
>> On Sun, Nov 1, 2015 at 2:03 AM, Julien Rouhaud
>> wrote:
>>> I'm also rather sceptical about this change.
>
>> Hm. Thinking a bit about this patch, it presents the advantage to be
>> able to track the same queries easi
Michael Paquier writes:
> On Sun, Nov 1, 2015 at 2:03 AM, Julien Rouhaud
> wrote:
>> I'm also rather sceptical about this change.
> Hm. Thinking a bit about this patch, it presents the advantage to be
> able to track the same queries easily across systems even if those
> tables have been created
On Sun, Nov 1, 2015 at 2:03 AM, Julien Rouhaud
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello,
>
> On 10/10/2015 08:46, Satoshi Nagayasu wrote:
>> On 2015/10/03 6:18, Peter Geoghegan wrote:
>>> On Wed, Sep 2, 2015 at 7:41 PM, Satoshi Nagayasu
>>> wrote:
I know this still
On Sat, Oct 31, 2015 at 10:03 AM, Julien Rouhaud
wrote:
>> At least, I would like to give some options to be chosen by the
>> user. Is it possible and/or reasonable?
>>
>
> I'm also rather sceptical about this change.
Is anyone willing to argue for it, apart from Satoshi?
--
Peter Geoghegan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
On 10/10/2015 08:46, Satoshi Nagayasu wrote:
> On 2015/10/03 6:18, Peter Geoghegan wrote:
>> On Wed, Sep 2, 2015 at 7:41 PM, Satoshi Nagayasu
>> wrote:
>>> I know this still needs to be discussed, but I would like to
>>> submit a patch for fur
On 2015/10/03 6:18, Peter Geoghegan wrote:
On Wed, Sep 2, 2015 at 7:41 PM, Satoshi Nagayasu wrote:
I know this still needs to be discussed, but I would like to submit
a patch for further discussion at the next CF, 2015-11.
I think I already expressed this in my explanation of the current
beha
On Wed, Sep 2, 2015 at 7:41 PM, Satoshi Nagayasu wrote:
> I know this still needs to be discussed, but I would like to submit
> a patch for further discussion at the next CF, 2015-11.
I think I already expressed this in my explanation of the current
behavior, but to be clear: -1 from me to this p
On 2015/09/01 14:39, Satoshi Nagayasu wrote:
> On 2015/09/01 14:01, Tom Lane wrote:
>> Satoshi Nagayasu writes:
>>> On 2015/09/01 13:41, Peter Geoghegan wrote:
If you want to use the queryId field directly, which I recall you
mentioning before, then that's harder. There is simply no cont
On 2015/09/01 14:01, Tom Lane wrote:
> Satoshi Nagayasu writes:
>> On 2015/09/01 13:41, Peter Geoghegan wrote:
>>> If you want to use the queryId field directly, which I recall you
>>> mentioning before, then that's harder. There is simply no contract
>>> among extensions for "owning" a queryId. B
Satoshi Nagayasu writes:
> On 2015/09/01 13:41, Peter Geoghegan wrote:
>> If you want to use the queryId field directly, which I recall you
>> mentioning before, then that's harder. There is simply no contract
>> among extensions for "owning" a queryId. But when the fingerprinting
>> code is moved
On 2015/09/01 13:41, Peter Geoghegan wrote:
On Mon, Aug 31, 2015 at 9:29 PM, Satoshi Nagayasu wrote:
BTW, I'm interested in improving the queryid portability now because
I'd like to use it in other extensions. :)
That's the reason why I'm looking at query jumbling here.
Are you interested in
On Mon, Aug 31, 2015 at 9:29 PM, Satoshi Nagayasu wrote:
> BTW, I'm interested in improving the queryid portability now because
> I'd like to use it in other extensions. :)
> That's the reason why I'm looking at query jumbling here.
Are you interested in having the query fingerprinting/jumbling
i
On 2015/09/01 12:36, Peter Geoghegan wrote:
On Mon, Aug 31, 2015 at 8:32 PM, Satoshi Nagayasu wrote:
Why don't we use relation name (with looking up the catalog)
on query jumbling? For performance reason?
I think that there is a good case for preferring this behavior. While
it is a little c
On Mon, Aug 31, 2015 at 8:32 PM, Satoshi Nagayasu wrote:
> Why don't we use relation name (with looking up the catalog)
> on query jumbling? For performance reason?
I think that there is a good case for preferring this behavior. While
it is a little confusing that pg_stat_statements does not chan
Hi,
I have a question on jumbling queries in pg_stat_statements.
I found that JumbleRangeTable() uses relation oid in
RangeTblEntry.
Obviously, this would result different queryid when the table
gets re-created (dropped and created).
Why don't we use relation name (with looking up the catalog)
15 matches
Mail list logo