pg.ddx.io  pgsql-sql@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: David W Noon <dwnoon@spamtrap.ntlworld.com>
To: pgsql-sql@postgresql.org
Subject: Re: Performance on temp table inserts
Date: Wed, 21 May 2003 12:03:13 +0100
Message-ID: <i03sp-5j3.ln1@my-pc.ntlworld.com> (raw)
References: <baba9i$2vi8$1@news.hub.org>
	<4d5op-4h3.ln1@my-pc.ntlworld.com>
	<badklp$uot$1@news.hub.org>

On Tuesday 20 May 2003 17:21 in <badklp$uot$1@news.hub.org>, Jeff Boes
(jboes@nexcerpt.com) wrote:

> 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 ...

Ok.

> 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.)

The reason I suggested a VACUUM was that my thought processes on this
problem lead me to the same conclusion I would have come to 25 years ago:
DASD fragmentation.

My reasoning is that the PostgreSQL catalogue on the test box is possibly
more fragmented than on the production box because developers tend to do
more CREATEs and DROPs of new tables than do production users. Moreover,
the DASD farm backing PostgreSQL could be similarly fragmented. If a VACUUM
does not have a beneficial effect then it would seem that the underlying
physical filesystem could be severely fragmented.

-- 
Regards,

Dave  [RLU#314465]
======================================================
dwnoon@spamtrap.ntlworld.com (David W Noon)
Remove spam trap to reply via e-mail.
======================================================



view thread (9+ messages)

Message-ID: <i03sp-5j3.ln1@my-pc.ntlworld.com>
Permalink:  ../i03sp-5j3.ln1@my-pc.ntlworld.com/
Also on:    postgresql.org/message-id/i03sp-5j3.ln1@my-pc.ntlworld.com

 · 

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-sql@postgresql.org
  Cc: dwnoon@spamtrap.ntlworld.com
  Subject: Re: Performance on temp table inserts
  In-Reply-To: <i03sp-5j3.ln1@my-pc.ntlworld.com>

* 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