Re: Fast insertion indexes: why no developments - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Fast insertion indexes: why no developments
Date
Msg-id CA+U5nML0H8unJ6K6Vr0t9KsFq5gvRw02bmfzy=Ky2G35vg=udA@mail.gmail.com
Whole thread Raw
In response to Re: Fast insertion indexes: why no developments  (Leonardo Francalanci <m_lists@yahoo.it>)
Responses Re: Fast insertion indexes: why no developments  (Leonardo Francalanci <m_lists@yahoo.it>)
List pgsql-hackers
On 5 November 2013 08:32, Leonardo Francalanci <m_lists@yahoo.it> wrote:
> Simon Riggs wrote
>> Everybody on this thread is advised to look closely at Min Max indexes
>> before starting any further work.
>>
>> MinMax will give us access to many new kinds of plan, plus they are
>> about as close to perfectly efficient, by which I mean almost zero
>> overhead, with regard to inserts as it is possible to get.
>
> Simon, I don't understand how minmax indexes would help in a random-inserts
> scenario.
> While I would love to use minmax for other columns (since we also partition
> and search based on a timestamp, which is usually well clustered), I thought
> minmax index would be perfect in a mostly-incremental values scenario.

Minmax indexes seem to surprise many people, so broad generalisations
aren't likely to be useful.

I think the best thing to do is to publish some SQL requests that
demonstrate in detail what you are trying to achieve and test them
against minmax indexes. That way we can discuss what does work and
what doesn't work well enough yet.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Albe Laurenz
Date:
Subject: Re: UTF8 national character data type support WIP patch and list of open issues.
Next
From: Sameer Kumar
Date:
Subject: Re: Re: Using indexes for ORDER BY and PARTITION BY clause in windowing functions