From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Thomas Kellerer <shammat(at)gmx(dot)net>, "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org> |
Subject: | Re: PostgreSQL does not choose my indexes well |
Date: | 2020-04-23 15:29:39 |
Message-ID: | 4315.1587655779@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Thursday, April 23, 2020, Thomas Kellerer <shammat(at)gmx(dot)net> wrote:
>> Plus: scanning idx_tabla_entidad is more efficient because that index is
>> smaller.
> Really? The absence of 33 million rows in the partial index seems like it
> would compensate fully and then some for the extra included columns.
On the other hand, an indexscan is likely to end up being effectively
random-access rather than the purely sequential access involved in
a seqscan. (If the index was built recently, then it might not be
so bad --- but the planner doesn't know that, so it assumes that the
index leaf pages are laid out pretty randomly.) Moreover, unless the
table is mostly marked all-visible, there will be another pile of
randomized accesses into the heap to validate visibility of the index
entries.
Bottom line is that this choice is not nearly as open-and-shut as
the OP seems to think. In fact, it's fairly likely that this is a
badly designed index, not a well-designed one that the planner is
unaccountably failing to use. Both covering indexes and partial
indexes are easily-misused features that can make performance worse
not better.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Lewis | 2020-04-23 16:20:41 | Re: PostgreSQL does not choose my indexes well |
Previous Message | David G. Johnston | 2020-04-23 13:57:29 | Re: PostgreSQL does not choose my indexes well |