Re: pg_stat_statements: calls under-estimation propagation

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Sameer Thakur <samthakur74(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_stat_statements: calls under-estimation propagation
Date: 2013-12-06 21:31:17
Message-ID: CAM3SWZR=TTnitUjEwbeKbr4x0O5oLZkyLrtFttOhnsKM1yTcmQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 6, 2013 at 12:24 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> There seems to be no problem even if we use bigint as the type of
>> unsigned 32-bit integer like queryid. For example, txid_current()
>> returns the transaction ID, i.e., unsigned 32-bit integer, as bigint.
>> Could you tell me what the problem is when using bigint for queryid?
>
> We're talking about the output of some view, right, not internal storage?
> +1 for using bigint for that. Using OID is definitely an abuse, because
> the value *isn't* an OID. And besides, what if we someday decide we need
> 64-bit keys not 32-bit?

Fair enough. I was concerned about the cost of external storage of
64-bit integers (unlike query text, they might have to be stored many
times for many distinct intervals or something like that), but in
hindsight that was fairly miserly of me.

Attached revision displays signed 64-bit integers instead.

--
Peter Geoghegan

Attachment Content-Type Size
pg_stat_statements-identification-v12.patch text/x-patch 19.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2013-12-06 21:34:59 Re: WITHIN GROUP patch
Previous Message Andrew Gierth 2013-12-06 21:30:58 Re: WITHIN GROUP patch