| From: | Michael Lewis <mlewis(at)entrata(dot)com> |
|---|---|
| To: | Rémi Chatenay <remi(dot)chatenay(at)doctolib(dot)com> |
| Cc: | Adam Brusselback <adambrusselback(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Pgsql Performance <pgsql-performance(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: How to deal with analyze gathering irrelevant stats |
| Date: | 2021-01-11 18:26:58 |
| Message-ID: | CAHOFxGr1qAjO82Mox2zC_ZV7S2Uy=oZ+HTV=vOONgbnhUxQ=yg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Mon, Jan 11, 2021 at 9:52 AM Rémi Chatenay <remi(dot)chatenay(at)doctolib(dot)com>
wrote:
> I'd say it's a 1 insert for 5 - 10 updates.
>
> As for the index on the status, it's because we have a job that runs every
> night that deals with conversations in specific statuses. Having a low
> cardinality index that changes frequently seems prone to mis-use by the
> system. -> What would be an alternative ?
>
One option would be a partial index on another field used in that query *where
status in ( list_of_uncommon_statuses_queried_nightly )*
Sequential scan may be perfectly fine for a nightly script though.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | M Tarkeshwar Rao | 2021-01-14 12:09:51 | RE: Need information on how MM frees up disk space (vaccum) after scheduled DB cleanup by BGwCronScript/BGwLogCleaner |
| Previous Message | Rémi Chatenay | 2021-01-11 16:52:25 | Re: How to deal with analyze gathering irrelevant stats |