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 bb86caf6-7cea-96bf-4d81-4f6e962974a6@BlueTreble.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Adding new output parameter of pg_stat_statements to identify operation of the query.  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 2/19/17 10:02 PM, Tom Lane wrote:
> 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.

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)



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] foreign partition DDL regression tests
Следующее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] dropping partitioned tables without CASCADE