Re: Performance on temp table inserts

On Tuesday 20 May 2003 17:21 in <badklp$uot$1(at)news(dot)hub(dot)org>, Jeff Boes
(jboes(at)nexcerpt(dot)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(at)spamtrap(dot)ntlworld(dot)com (David W Noon)
Remove spam trap to reply via e-mail.
======================================================