Re: slow bitmap heap scans on pg 9.2

From: Steve Singer <ssinger(at)ca(dot)afilias(dot)info>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: slow bitmap heap scans on pg 9.2
Date: 2013-04-19 17:04:40
Message-ID: 51717928.2010602@ca.afilias.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 13-04-14 08:06 PM, Steve Singer wrote:
> On 13-04-13 04:54 PM, Jeff Janes wrote:

>>
>> If you are trying to make your own private copy of 9.2, then removing
>> the fudge factor altogether is probably the way to go. But if you want
>> to help improve future versions, you probably need to test with the most
>> up-to-date dev version.
>
> I will do that in a few days. I don't have enough disk space on this
> dev server to have a 9.2 datadir and a 9.3 one for this database. Once
> I have a solution that I can use with 9.2 firmed up I can upgrade the
> datadir to 9.3 and test this. I am hoping I can get a set of partial
> indexes that will give good results with an unmodified 9.2, so far that
> looks promising but I still have more cases to verify (these indexes
> take a while to build).
>

I've run these queries against a recent master/9.3 and the planner is
picking the nested-loop plan for using the full index. This is with
random_page_cost=2.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Rodrigo Barboza 2013-04-19 21:55:18 maintenance_work_mem and autovacuum_max_workers
Previous Message Tom Lane 2013-04-18 21:42:15 Re: Query planner ignoring constraints on partitioned tables when joining