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

From Merlin Moncure
Subject Re: Fast insertion indexes: why no developments
Date
Msg-id CAHyXU0x8MPH-=FNVOKUVppkM11BVWyzVNoe8HBPTmG2v_1bctQ@mail.gmail.com
Whole thread Raw
In response to Re: Fast insertion indexes: why no developments  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Fast insertion indexes: why no developments  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Fast insertion indexes: why no developments  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Wed, Nov 13, 2013 at 7:33 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 13 November 2013 09:31, Leonardo Francalanci <m_lists@yahoo.it> wrote:
>> I would like to see some numbers.
>
> Alvaro has given me some results for his patch. The figures I have are
> for a 2GB table.
>
> Index Build Time
> MinMax 11 s
> Btree   96s
>
> Index Size
> MinMax 2 pages + metapage
> Btree approx 200,000 pages + metapage
>
> Load time
> MinMax no overhead, same as raw COPY
> BTree - considerably slower
>
> Index SELECT
> Slower for small groups of rows
> Broadly same for large requests (more results required on that assessment)
>
> I expect to publish results against TPC-H cases in next few weeks.
>
> Additional tests are welcome for other use cases.

Those are pretty exciting numbers.  These days for analytics work I'm
using mostly covering index type approaches.  I bet the tiny index
would more than offset the extra heap accesses.   Can you CLUSTER
against a minmax index?

merlin



pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: additional json functionality
Next
From: Simon Riggs
Date:
Subject: Re: Fast insertion indexes: why no developments