pg_trigger.tgparentid

Поиск
Список
Период
Сортировка
Искать
От
Alvaro Herrera
Тема
pg_trigger.tgparentid
Дата
Msg-id
20200217215641.GA29784@alvherre.pgsql
Список
Дерево обсуждения
pg_trigger.tgparentid Alvaro Herrera <alvherre@2ndquadrant.com>
Re: pg_trigger.tgparentid Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_trigger.tgparentid Amit Langote <amitlangote09@gmail.com>
Re: pg_trigger.tgparentid Amit Langote <amitlangote09@gmail.com>
Re: pg_trigger.tgparentid Alvaro Herrera <alvherre@2ndquadrant.com>
Re: pg_trigger.tgparentid Amit Langote <amitlangote09@gmail.com>
Re: pg_trigger.tgparentid Alvaro Herrera <alvherre@2ndquadrant.com>
Re: pg_trigger.tgparentid Amit Langote <amitlangote09@gmail.com>
Re: pg_trigger.tgparentid Alvaro Herrera <alvherre@2ndquadrant.com>
Re: pg_trigger.tgparentid Tom Lane <tgl@sss.pgh.pa.us>
As mentioned in https://postgr.es/m/20191231194759.GA24692@alvherre.pgsql
I propose to add a new column to pg_trigger, which allows us to remove a
pg_depend scan when cloning triggers when adding/attaching partitions.
(It's not that I think the scan is a performance problem, but rather
than notionally we try not to depend on pg_depend contents for this kind
of semantic derivation.)

-- 
Álvaro Herrera                            39°49'30"S 73°17'W
В списке pgsql-hackers по дате отправления
От: Tom Mercha
Дата:
Сообщение: SPI Concurrency Precautions?
От: Vik Fearing
Дата:
FAQ