On Thu, Aug 18, 2016 at 6:27 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Claudio Freire <klaussfre...@gmail.com> writes: >> On Thu, Aug 18, 2016 at 6:04 PM, Kevin Grittner <kgri...@gmail.com> wrote: >>> Speaking of performance side effects, does this avoid O(N^2) >>> performance on index tuple insertion with duplicate values, for all >>> insertion orderings? For example, does it descend directly to the >>> right leaf page for the insert rather than starting at the front of >>> the block of duplicate values and scanning to the right for a >>> block with space, with a random chance to split a full block on >>> each page it moves through? > >> Yes, but only on non-unique indexes. > > How's that work if the existing entries aren't in TID order (which they > will not be, in a pre-existing index)? Or are you assuming you can blow > off on-disk compatibility of indexes? > > regards, tom lane
This patch does blow off on-disk compatibility, but the plan is to re-add it later on. A flag in the meta page would indicate whether it's a sorted index or not, and the only way to get a sorted index would be with a reindex. The code would have to support both for a while until whatever point we'd figure we can drop support for old format indexes. Since this is a sort order change I see no alternative, either the whole index is sorted by TID or not. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
