Re: [HACKERS] Adding new output parameter of pg_stat_statements toidentify operation of the query.
От | Jim Nasby |
---|---|
Тема | Re: [HACKERS] Adding new output parameter of pg_stat_statements toidentify operation of the query. |
Дата | |
Msg-id | 0b63b6d5-4ae8-528a-30e4-38a2d86ec0d6@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Adding new output parameter of pg_stat_statements toidentify operation of the query. ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>) |
Ответы |
Re: [HACKERS] Adding new output parameter of pg_stat_statements to identify operation of the query.
|
Список | pgsql-hackers |
On 2/19/17 6:34 PM, Tsunakawa, Takayuki wrote: >> We have done the job and are willing to post a patch. >> I sent one through my work mail, but it seems that my mail didn't reach >> the maillist, so I try again by using my personal mail account. > A view for counting the number of executions per operation type is being developed for PostgreSQL 10, which is expectedto be released this year. > > https://commitfest.postgresql.org/13/790/ > > Would this fit your need? If not, what's the benefit of getting the operation type via pg_stat_statements? 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. Short of that, I'm not sure it would be a good idea to only support a single tag being visible at a time; it would be certain to induce users to create code that's going to be buggy as soon as someone starts using multiple statements. -- 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 по дате отправления: