Re: Adding new output parameter of pg_stat_statements to identify operation of the query.

On 2/19/17 10:02 PM, Tom Lane wrote:
> Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)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)