MIME-Version: 1.0
In-Reply-To: 
 <CAB9893izHQaPTk1bGEDs8UTQUTKtpj1sk6PLyWrvXU-j0JBFaQ@mail.gmail.com>
References: 
 <CAB9893izHQaPTk1bGEDs8UTQUTKtpj1sk6PLyWrvXU-j0JBFaQ@mail.gmail.com>
From: David Rowley <david.rowley@2ndquadrant.com>
Date: Thu, 14 Sep 2017 09:57:54 +1200
Message-ID: 
 <CAKJS1f-AkrKfLEsrb7ymZve_b3e9cTKUcEdeeeJkVWnOTVdPnA@mail.gmail.com>
Subject: Re: query of partitioned object doesnt use index in qa
To: Mike Broers <mbroers@gmail.com>
Cc: postgres performance list <pgsql-performance@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On 14 September 2017 at 08:28, Mike Broers <mbroers@gmail.com> wrote:
> I have a query of a partitioned table that uses the partition index in
> production but uses sequence scans in qa.  The only major difference I can
> tell is the partitions are much smaller in qa.  In production the partiti=
ons
> range in size from around 25 million rows to around 60 million rows, in QA
> the partitions are between 4 and 12 million rows.  I would think this wou=
ld
> be big enough to get the planner to prefer the index but this is the major
> difference between the two database as far as I can tell.


QA:

> =E2=94=82                           ->  Seq Scan on event__99999999 e_1
> (cost=3D0.00..2527918.06 rows=3D11457484 width=3D782)            =E2=94=82
>

Production:
>
> =E2=94=82                           ->  Index Scan using
> ix_event__00011162_landing_id on event__00011162 e_1  (cost=3D0.56..15476=
.59
> rows=3D23400 width=3D572)               =E2=94=82


If QA has between 4 and 12 million rows, then the planner's row
estimate for the condition thinks 11457484 are going to match, so a
Seqscan is likely best here. If those estimates are off then it might
be worth double checking your nightly analyze is working correctly on
QA.

The planner may be able to be coaxed into using the index with a
higher effective_cache_size and/or a lower random_page_cost setting,
although you really should be looking at those row estimates first.
Showing us the EXPLAIN ANALYZE would have been much more useful so
that we could have seen if those are accurate or not.

--=20
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


--=20
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance