| From: | Michael Lewis <mlewis(at)entrata(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Cosmin Prund <cprund(at)gmail(dot)com>, Pgsql Performance <pgsql-performance(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Bad query plan decision when using multiple column index - postgresql uses only first column then filters |
| Date: | 2020-01-16 16:59:40 |
| Message-ID: | CAHOFxGpHTpPDAJKj1MtwmJSQ266_0vXwRnJbAbQ=ah73h2r27w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Does the behavior change with different values of Ver column? I'd be
curious of the fraction in the MCVs frequency list in stats indicates that
rows with Ver = 92 are rare and therefore the index on only Ver column is
sufficient to find the rows quickly. What is reltuples for this table by
the way?
I also wonder if the situation may be helped by re-indexing the "index on
both columns" to remove any chance of issues on bloat in the index. Which
order are the columns by the way? If Ver is first, is there also an index
on only id column?. Since you aren't on v12, you don't get to re-index
concurrently but I assume you know the work around of create concurrently
(different name), drop concurrently (old one), and finally rename new index.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Cosmin Prund | 2020-01-16 17:18:24 | Re: Bad query plan decision when using multiple column index - postgresql uses only first column then filters |
| Previous Message | Tom Lane | 2020-01-16 15:11:26 | Re: Bad query plan decision when using multiple column index - postgresql uses only first column then filters |