From: Steinar H. Gunderson <sgunderson@bigfoot.com>
To: pgsql-performance@postgresql.org
Subject: Re: Materializing a sequential scan
Date: Sun, 23 Oct 2005 12:23:33 +0200
Message-ID: <20051023102333.GA9356@samfundet.no> (raw)
In-Reply-To: <4248.1129783045@sss.pgh.pa.us>
References: <20051019174544.GA32303@samfundet.no>
<4248.1129783045@sss.pgh.pa.us>
On Thu, Oct 20, 2005 at 12:37:25AM -0400, Tom Lane wrote:
> That mdb_gruppekobling_transitiv_tillukning function looks awfully
> grotty ... how many rows does it return, and how long does it take to
> run by itself? How often does its temp table get vacuumed? A quick
> band-aid might be to use TRUNCATE instead of DELETE FROM to clean the
> table ... but if I were you I'd try to rewrite the function entirely.
I've verified that it indeed does use 20ms more for every run without a
VACUUM, but it shouldn't really matter -- and I guess it will go away once
somebody teaches plpgsql about not caching OIDs for CREATE TEMPORARY TABLE.
:-)
In any case, I still can't understand why it picks the plan it does; what's
up with the materialized seqscan, and where do the four million rows come
from? 7.4 estimates ~52000 disk page fetches for the same query, so surely
there must be a better plan than four million :-)
/* Steinar */
--
Homepage: http://www.sesse.net/
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: sgunderson@bigfoot.com
Subject: Re: Materializing a sequential scan
In-Reply-To: <20051023102333.GA9356@samfundet.no>
* 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