From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Erik Rijkers <er(at)xs4all(dot)nl> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Minmax indexes |
Date: | 2013-11-11 17:15:53 |
Message-ID: | CAMkU=1xiBuZnhtwab8f6NXDCQNFu+VHd9gb4ZUqvYBXfB6LXjg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 11, 2013 at 12:53 AM, Erik Rijkers <er(at)xs4all(dot)nl> wrote:
> On Fri, November 8, 2013 21:11, Alvaro Herrera wrote:
> >
> > Here's a version 7 of the patch, which fixes these bugs and adds
> > opclasses for a bunch more types (timestamp, timestamptz, date, time,
> > timetz), courtesy of Martín Marqués. It's also been rebased to apply
> > cleanly on top of today's master branch.
> >
> > I have also added a selectivity function, but I'm not positive that it's
> > very useful yet.
> >
> > [minmax-7.patch]
>
> The earlier errors are indeed fixed; now, I've been trying with the
> attached test case but I'm unable to find a query that
> improves with minmax index use. (it gets used sometimes but speedup is
> negligable).
>
Your data set seems to be completely random. I believe that minmax indices
would only be expected to be useful when the data is clustered. Perhaps
you could try it on a table where it is populated something like
i+random()/10*max_i.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Rohit Goyal | 2013-11-11 17:16:29 | Re: Fwd: Test of Algorithm || Indexing Scheme |
Previous Message | Tom Lane | 2013-11-11 17:01:40 | Re: Add %z support to elog/ereport? |