Re: [HACKERS] Adding new output parameter of pg_stat_statements toidentify operation of the query. - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: [HACKERS] Adding new output parameter of pg_stat_statements toidentify operation of the query.
Date
Msg-id bb86caf6-7cea-96bf-4d81-4f6e962974a6@BlueTreble.com
Whole thread Raw
In response to Re: [HACKERS] Adding new output parameter of pg_stat_statements to identify operation of the query.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2/19/17 10:02 PM, Tom Lane wrote:
> Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
>> Something that needs to be considered with doing this in
>> pg_stat_statement is that a query that's reported there can contain
>> multiple SQL statements. I don't remember offhand if all statements get
>> parsed as a whole before anything else happens; if that's the case then
>> you could potentially have an array in pg_stat_statements indicating
>> what the command tags are.
> I think that's been addressed as of 83f2061dd.
>
> My own concern here is that pg_stat_statements shared hashtable entries
> (pgssEntry) are currently 200 bytes, if I counted correctly.  It's hard
> to see how to implement this feature without adding COMPLETION_TAG_BUFSIZE
> (64 bytes) to that, which is kind of a large percentage bump for a feature
> request that AFAIR nobody else has ever made.

AFAIK the only variable part of any tag is the rowcount from SELECT (if 
that's even part of the tag?)... so couldn't tags be switched over to an 
enum, at least internally?
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: [HACKERS] foreign partition DDL regression tests
Next
From: Amit Langote
Date:
Subject: Re: [HACKERS] dropping partitioned tables without CASCADE