From: Jeff Boes <jboes@nexcerpt.com>
Subject: Re: Performance on temp table inserts
Date: Tue, 20 May 2003 12:21:13 -0400
Organization: Nexcerpt, Inc.
Lines: 36
Message-ID: <badklp$uot$1@news.hub.org>
References: <baba9i$2vi8$1@news.hub.org> <4d5op-4h3.ln1@my-pc.ntlworld.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Pan/0.11.4 (Unix)
To: pgsql-sql@postgresql.org

On Mon, 19 May 2003 19:19:32 -0400, David W Noon wrote:

> On Monday 19 May 2003 20:11 in <baba9i$2vi8$1@news.hub.org>, Jeff Boes
> (jboes@nexcerpt.com) wrote:
> 
>> What factors affect the performance of a temp table insert?
> 
> I would run an EXPLAIN on each of the two servers and see what
> differences there are in the respective execution strategies.
> 

Hmm ... I'm not sure you followed my original post.  However, in the
interests of science:

explain insert into temp_link_checksums values ('a');
NOTICE:  QUERY PLAN:

Result  (cost=0.00..0.01 rows=1 width=0)

EXPLAIN

This is identical on the two systems.  As I would expect for an insert
statement ...

> Also, a VACUUM ANALYZE might be of interest to speed up the slower box.

But the table doesn't exist before I create and insert it. (Well,
actually it does: after the first CREATE, the subsequent uses of the
table are preceded by TRUNCATE TABLE, so it exists but is empty.  I dunno
what a VACUUM ANALYZE will do for an insert, though.)

-- 
Jeff Boes                                      vox 269.226.9550 ext 24
Database Engineer                                     fax 269.349.9076
Nexcerpt, Inc.                                 http://www.nexcerpt.com
           ...Nexcerpt... Extend your Expertise