Heikki Linnakangas <hlinn...@iki.fi> writes: > On 09/24/2016 02:34 PM, Peter Geoghegan wrote: >> I go on to explain how this patch represents a partial solution to >> that [1]. That's what I mean by "useful practical consequences". As I >> say in [1], I think we could even get a full solution, if we applied >> this patch and *also* made the ordering in which the relcache returns >> a list of index OIDs more useful (it should still be based on >> something stable, to avoid deadlocks, but more than just OID order. >> Instead, relcache.c can sort indexes such that we insert into primary >> keys first, then unique indexes, then all other indexes. This also >> avoids bloat if there is a unique violation, by getting unique indexes >> out of the way first during ExecInsert()).
> Hmm, yeah, that'd be nice to fix. I'd like to see a patch specifically > to fix that. I'm not convinced that we need all the complications of > this patch, to get that fixed. (In particular, indexam's still wouldn't > need to care about the different between CHECK_UNIQUE_PARTIAL and > CHECK_UNIQUE_SPECULATIVE, I think.) I can see the value of processing unique indexes before non-unique ones. I'm pretty suspicious of trying to prioritize primary keys first, though, because (a) it's not clear why bother, and (b) PG is a tad squishy about whether an index is a primary key or not, so that I'd be worried about different backends sometimes choosing different orders. I'd simplify this to "uniques in OID order then non-uniques in OID order". regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers