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

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.

I suppose one way to avoid a large fixed-size field would be to store
the tag string out-of-line, similarly to what we do with the query text.
But then you've traded off a shared-memory-bloat worry for a performance
worry, ie what's the added overhead for dealing with another external
string.
        regards, tom lane