Re: Partial index creation always scans the entire table - Mailing list pgsql-performance

From Tom Lane
Subject Re: Partial index creation always scans the entire table
Date
Msg-id 19549.1581867005@sss.pgh.pa.us
Whole thread Raw
In response to Re: Partial index creation always scans the entire table  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: Partial index creation always scans the entire table  (Justin Pryzby <pryzby@telsasoft.com>)
RE: Partial index creation always scans the entire table  ("Mike Sofen" <msofen@runbox.com>)
List pgsql-performance
Laurenz Albe <laurenz.albe@cybertec.at> writes:
> On Sat, 2020-02-15 at 19:04 +0800, MingJu Wu wrote:
>> My scenario is that I have a table with 50M rows that are categorized into 10K categories.
>> I need to create a partial index for each category.

> You don't need a partial index per category, you need a single index that *contains* the category.

Yeah, that's an anti-pattern.  Essentially, you are trying to replace the
first branching level of an index that includes the category column with
a ton of system catalog entries and planner proof logic to select one of
N indexes that don't include the category.  It is *highly* unlikely that
that's going to be a win.  It's going to be a huge loss if the planner
fails to make the proof you need, and even when it does, it's not really
going to be faster overall --- you've traded off run-time for planning
time, at a rather unfavorable exchange rate.  Updates on the table are
going to be enormously penalized, too, because the index machinery doesn't
have any way to understand that only one of the indexes needs work.

I've seen people try to do this before.  I wonder if the manual page
about partial indexes should explicitly say "don't do that".

            regards, tom lane



pgsql-performance by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: Partial index creation always scans the entire table
Next
From: Justin Pryzby
Date:
Subject: Re: Partial index creation always scans the entire table