Re: transition tables and UPDATE

Поиск
Список
Период
Сортировка
От Corey Huinker
Тема Re: transition tables and UPDATE
Дата
Msg-id CADkLM=dhxN-8TLdOa6tPxSzZTfTHO0SKzp8pSAUbg5pozgsd4g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: transition tables and UPDATE  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers

even uglier than what I already had.  So yeah, I think it might be
useful if we had a way to inject a counter or something in there.


This came up for me when I was experimenting with making the referential integrity triggers fire on statements rather than rows. Doing so has the potential to take a lot of the sting out of big deletes where the referencing column isn't indexed (thus resulting in N sequentials scans of the referencing table). If that were 1 statement then we'd get a single (still ugly) hash join, but it's an improvement.

It has been suggested that the the overhead of forming the tuplestores of affected rows and reconstituting them into EphemerialNamedRelations could be made better by instead storing an array of old ctids and new ctids, which obviously would be in the same order, if we had a means of reconstituting those with just the columns needed for the check (and generating a fake ordinality column for your needs), that would be considerably lighter weight than the tuplestores, and it might make statement level triggers more useful all around.

 

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: a very minor bug and a couple of comment changes for basebackup.c
Следующее
От: Nikolay Samokhvalov
Дата:
Сообщение: Re: Amcheck verification of GiST and GIN