Re: Single column vs composite partial index

From: Michael Lewis <mlewis(at)entrata(dot)com>
To: Nagaraj Raj <nagaraj(dot)sf(at)yahoo(dot)com>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Pgsql Performance <pgsql-performance(at)lists(dot)postgresql(dot)org>
Subject: Re: Single column vs composite partial index
Date: 2020-09-18 20:54:04
Message-ID: CAHOFxGqpPij+tC4qOO6ijJjax_PtYmQuJ_0T=Z-WpqYE9gS51Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Index Cond: ((load_dttm)::date >= (CURRENT_DATE - 7))"

There is no need to cast the load_dttm field to a date in the query. The
plain index on the field would be usable if you skipped that. In your
example, you show creating the single column index but it isn't getting
used because of the type cast. The second index is both partial, and
multi-column. If your data statistics show that ((actv_code)::text = ANY
('{NAC,CAN,RSP,RCL}'::text[])) only 1% of the time, then it would certainly
be helpful to have a partial index if those are the rows you want to find
often and do so quickly. If the rows with those values for actv_code is
more like 75% of the total rows, then there'd be no reason to make it
partial IMO.

If you are often/constantly querying for only the last 7-7.999 days of data
based on load_dttm, I would put that as the first column of the index since
then you would be scanning a contiguous part rather than scanning 3
different parts of the composite index where actv_code = each of those
three values, and then finding the rows that are recent based on the
timestamp(tz?) field.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Michael Paquier 2020-09-24 03:56:37 Re: proposal: schema variables
Previous Message Tom Lane 2020-09-16 14:17:33 Re: Performance issue when we use policies for Row Level Security along with functions