From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | John Lumby <johnlumby(at)hotmail(dot)com> |
Cc: | pgsql general <pgsql-general(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: REINDEX : new parameter to preserve current average leaf density as new implicit FILLFACTOR |
Date: | 2019-07-10 04:04:27 |
Message-ID: | CAH2-Wz=Avtf33QP+c2KcA9idkTcq9kek68VN5gfYURSVff+ZBQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Jul 9, 2019 at 3:18 PM John Lumby <johnlumby(at)hotmail(dot)com> wrote:
> > Or, it could be that range scan performance benefitted from reduced fragmentation,
> >
>
> Yes, I think so.
ISTM that the simplest explanation here is that index fragmentation
(and even index size) is a red herring, and the real issue is that
you're suffering from problems similar to those that are described in
these old threads:
https://www.postgresql.org/message-id/flat/20160524173914.GA11880%40telsasoft.com
https://www.postgresql.org/message-id/flat/520D6610.8040907%40emulex.com
There have been numerous reports from users with problems involving
low cardinality indexes that gradually became less correlated with the
underlying table over time. At least a couple of these users found
that a periodic REINDEX temporarily fixed the problem -- see the first
thread for an example. Postgres 12 maintains the heap/table sort order
among duplicates by treating heap TID as a tiebreaker column, which
may make REINDEXing totally unnecessary for you. It's harder to model
this issue because the problem with heap TID order will only be seen
when there is at least a moderate amount of churn.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2019-07-10 04:53:42 | Re: REINDEX : new parameter to preserve current average leaf density as new implicit FILLFACTOR |
Previous Message | Ian Barwick | 2019-07-10 02:35:15 | Re: Restoring a database restores to unexpected tablespace |