Jim Nasby <jim.na...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers