Skip site navigation (1) Skip section navigation (2)

Re: Loose Index Scans by Planner?

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: sthomas(at)optionshouse(dot)com
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Loose Index Scans by Planner?
Date: 2012-08-25 03:42:40
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-performance
On Fri, Aug 24, 2012 at 9:20 AM, Shaun Thomas <sthomas(at)optionshouse(dot)com> wrote:
> Maybe I should post this in Hackers instead, but I figured I'd start here to
> avoid cluttering up that list.
> So, we know we have a way of doing a loose index scan with CTEs:
> But that got me wondering. The planner knows from pg_stats that col1 could
> have low cardinality. If that's the case, and a WHERE clause uses a two
> column index, and col2 is specified, why can't it walk each individual
> bucket in the two-column index, and use col2? So I forced such a beast with
> a CTE:
>   SELECT min(col1) AS col1
>     FROM tablename
>   SELECT (SELECT min(col1)
>             FROM tablename
>            WHERE col1 > t.col1)
>     FROM t
>    WHERE t.col1 IS NOT NULL
> )
> SELECT p.*
>   FROM t
>   JOIN tablename p USING (col1)
>  where p.col2 = 12345

That is awesome.  I had never though of trying to do it that way.

> I ask, because while the long-term fix would be to re-order the index to
> (col2, col1),

Not always.  The case for having (col1,col2) might be very compelling.
 And having to maintain both orderings when just maintaining one would
be "good enough" would kind of suck.  Having the planner do the best
it can given the index it has is a good thing.

I would also note that having this feature (called "skip scan" in some
other products) would mimic what happens when you need to do a query
specifying col2 but not col1 on a table family which is list
partitioned on col1.  Getting some of the benefits of partitioning
without having to actually do the partitioning would be a good thing.

> this seems like a situation the planner could easily detect
> and compensate for.

Yes, it is just a Small Matter Of Programming :)

And one I've wanted for a while.

If only someone else would offer to do it for me....



In response to


pgsql-performance by date

Next:From: Felix SchubertDate: 2012-08-25 12:07:34
Subject: Slow Performance on a XEON E5504
Previous:From: Shaun ThomasDate: 2012-08-24 21:22:12
Subject: Re: Loose Index Scans by Planner?

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-08-25 04:38:09
Subject: Re: plperl sigfpe reset can crash the server
Previous:From: Robert HaasDate: 2012-08-25 01:51:13
Subject: Re: foreign key locks

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group