Message-ID: <ecab6bec627ea59c3dcc84f236e04d745caf0a79.camel@cybertec.at>
Subject: Re: Slow query performance inside a transaction on a clean database
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: val.janeiko@gmail.com, pgsql-performance@postgresql.org
Date: Mon, 08 Mar 2021 10:17:59 +0100
In-Reply-To: <002101d711e8$bfd8a490$3f89edb0$@gmail.com>
References: <002101d711e8$bfd8a490$3f89edb0$@gmail.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/ecab6bec627ea59c3dcc84f236e04d745caf0a79.camel%40cybertec.at>
Precedence: bulk

On Fri, 2021-03-05 at 17:55 +0000, val.janeiko@gmail.com wrote:
> I have a SELECT query that uses a long chain of CTEs (6) and is executed
> repeatedly as part of the transaction (with different parameters). It is
> executed quickly most of the time, but sometimes becomes very slow. I
> managed to consistently reproduce the issue by executing a transaction
> containing this query on an empty database. The query is fast for the first
> 150-170 inserted resources, but ~50% of the executions afterwards take 5.6s
> instead of 1.4ms. Additionally it only becomes slow if resources are
> inserted in a random order, if I insert resources sorted by
> `start_date_time` column the query is always fast.
> 
> Here are the results of EXPLAIN (ANALYZE, COSTS, VERBOSE, BUFFERS, FORMAT
> JSON):
> - Slow: https://explain.depesz.com/s/e4Fo
> - Fast: https://explain.depesz.com/s/7HFJ

If your transaction modifies the data significantly (which it does if the
table is empty before you start), you should throw in an ANALYZE on the
affected tables occasionally.

Normally, autovacuum takes care of that, but it cannot see your data
until the transaction is committed.

Yours,
Laurenz Albe
-- 
Cybertec | https://www.cybertec-postgresql.com