Re: pg_stat_statements: calls under-estimation propagation

Peter Geoghegan <pg@heroku.com>

From: Peter Geoghegan <pg@heroku.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Fujii Masao <masao.fujii@gmail.com>, Sameer Thakur <samthakur74@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2013-12-06T21:31:17Z
Lists: pgsql-hackers

Attachments

On Fri, Dec 6, 2013 at 12:24 PM, Tom Lane <tgl@sss.pgh.pa.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

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Improve management of "sticky" entries in contrib/pg_stat_statements.