From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
Cc: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, "'husttripper(at)vip(dot)sina(dot)com'" <husttripper(at)vip(dot)sina(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Adding new output parameter of pg_stat_statements to identify operation of the query. |
Date: | 2017-02-20 04:02:53 |
Message-ID: | 16740.1487563373@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2017-02-20 04:05:28 | Re: pg_dump emits ALTER TABLE ONLY partitioned_table |
Previous Message | Amit Langote | 2017-02-20 03:07:08 | Re: tab completion for partitioning |