pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Kevin Grittner <kgrittn@ymail.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Cc: Gunnlaugur Thor Briem <gunnlaugur@gmail.com>
Subject: Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
Date: Fri, 06 Mar 2015 20:38:14 -0500
Message-ID: <27245.1425692294@sss.pgh.pa.us> (raw)
In-Reply-To: <1407502480.21180.1425691482543.JavaMail.yahoo@mail.yahoo.com>
References: <54F9E179.4000804@2ndquadrant.com>
	<1407502480.21180.1425691482543.JavaMail.yahoo@mail.yahoo.com>
List-Unsubscribe:  <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>

Kevin Grittner <kgrittn@ymail.com> writes:
> Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
>> How would fccebe421 explain the large amount of random writes (~4MB/s
>> for more than an hour), reported in the initial post? And why would that
>> only affect the EXPLAIN and not the bare query?
>> But the random writes don't really match in this scenario ...

> Sure they do -- both the index and heap pages may be rewritten with
> hints that the rows are dead.

Hm ... yeah, this idea could match the symptoms: if the database has built
up a large debt of dead-but-unhinted rows, then the first pass through the
index would cause a write storm but the next would not, which would
explain why doing EXPLAIN immediately followed by the real query would put
all the hint-update burden on the EXPLAIN even though the planning phase
of the real query would inspect the same index entries.

But if that's the situation, those hint-updating writes would get done
sooner or later --- probably sooner, by actual execution of the query
itself.  So I'm not convinced that moving to SnapshotAny would fix
anything much, only change where the problem manifests.

Also, it's less than clear why only this particular query is showing
any stress.  Dead rows should be a hazard for anything, especially if
there are enough of them to require hours to re-hint.  And why wouldn't
autovacuum get to them first?

			regards, tom lane


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance



view thread (21+ messages)  latest in thread

Message-ID: <27245.1425692294@sss.pgh.pa.us>
Permalink:  ../27245.1425692294@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/27245.1425692294@sss.pgh.pa.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: tgl@sss.pgh.pa.us, kgrittn@ymail.com, tomas.vondra@2ndquadrant.com, gunnlaugur@gmail.com
  Subject: Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  In-Reply-To: <27245.1425692294@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox