| From: | Tim Kane <tim(dot)kane(at)gmail(dot)com> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Cc: | Michael Lewis <mlewis(at)entrata(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL mailing lists <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Avoiding out of date statistics / planner |
| Date: | 2020-02-13 13:19:19 |
| Message-ID: | CADVWZZLkvkPJY2fqqYJpYiOfXtNNGruQB2Z8KOsDi0zBj8z0_w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
That looks very useful indeed. Thanks Tomas
On Wed, Feb 12, 2020 at 8:32 PM Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
wrote:
> On Wed, Feb 12, 2020 at 10:23:22AM -0700, Michael Lewis wrote:
> >It may also be worth noting that it is possible to make autovacuum/analyze
> >more aggressive, perhaps only on the tables that see large changes in data
> >that might result in a statistics issue. If you could share a query,
> >explain analyze output, and pseudo code or at least description of what
> >sort of bulk operations are being done, then more insight could be
> offered.
>
> Another thing you can do is deploy auto_explain, and log explain plan
> for long-runnning queries. That won't fix the root cause, but it will
> help you with confirming the root cause - you'll see the query plan,
> which should give you enough context.
>
> regards
>
> --
> Tomas Vondra http://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sterpu Victor | 2020-02-13 13:34:55 | Enabling extensions on a compiled instance of postgresql 12.1 |
| Previous Message | Jason Ralph | 2020-02-13 12:31:42 | pg_upgrade —link does it remove table bloat |