Re: transition tables and UPDATE - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: transition tables and UPDATE
Date
Msg-id CADkLM=dhxN-8TLdOa6tPxSzZTfTHO0SKzp8pSAUbg5pozgsd4g@mail.gmail.com
Whole thread Raw
In response to Re: transition tables and UPDATE  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: a very minor bug and a couple of comment changes for basebackup.c
Next
From: Nikolay Samokhvalov
Date:
Subject: Re: Amcheck verification of GiST and GIN