Re: Avoiding out of date statistics / planner - Mailing list pgsql-general

From Tom Lane
Subject Re: Avoiding out of date statistics / planner
Date
Msg-id 23751.1581520559@sss.pgh.pa.us
Whole thread Raw
In response to Avoiding out of date statistics / planner  (Tim Kane <tim.kane@gmail.com>)
Responses Re: Avoiding out of date statistics / planner  (Michael Lewis <mlewis@entrata.com>)
List pgsql-general
Tim Kane <tim.kane@gmail.com> writes:
> Every now and again, I will encounter an unexplained long-running query.
> It’s a head scratcher moment, because this query that is still running for
> 20 minutes (not blocking) can be run independently in about 500ms

Without some kind of context (like, have you been doing something to
the table(s) involved that would drastically change their statistics)
it's hard to comment on this.  It's not obvious from the info
provided that this is a bad-plan issue rather than something else.

> On the application side, we can explicitly issue a VACUUM ANALYZE after
> each bulk operation - and often that is precisely what happens..
> But - I am keenly aware that this cannot be performed within a transaction.

Plain ANALYZE can be, and that's all you need if the problem is to
update stats.

            regards, tom lane



pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_basebackup connection closed unexpectedly...
Next
From: Dmitry Igrishin
Date:
Subject: Natural sort order extension.