Re: Fast insertion indexes: why no developments
От | Merlin Moncure |
---|---|
Тема | Re: Fast insertion indexes: why no developments |
Дата | |
Msg-id | CAHyXU0x8MPH-=FNVOKUVppkM11BVWyzVNoe8HBPTmG2v_1bctQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Fast insertion indexes: why no developments (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Fast insertion indexes: why no developments
Re: Fast insertion indexes: why no developments |
Список | 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 по дате отправления: