1.451 ms = 1.451 milliseconds
1451.0 ms = 1.451 seconds ...
so 32.918 ms for a commit seems perhaps reasonable ?
Greg Williamson
DBA
GlobeXplorer LLC
-----Original Message-----
From: pgsql-performance-owner@xxxxxxxxxxxxxx on behalf of Zeugswetter Andreas DCP SD
Sent: Thu 5/11/2006 12:55 AM
To: Jim C. Nasby; PFC
Cc: Greg Stark; Tom Lane; pgsql-performance@xxxxxxxxxxxxxx; pgsql-hackers@xxxxxxxxxxxxxx
Subject: Re: [PERFORM] [HACKERS] Big IN() clauses etc : feature proposal
> Something else worth considering is not using the normal
> catalog methods
> for storing information about temp tables, but hacking that together
> would probably be a rather large task.
But the timings suggest, that it cannot be the catalogs in the worst
case
he showed.
> 0.101 ms BEGIN
> 1.451 ms CREATE TEMPORARY TABLE tmp ( a INTEGER NOT NULL, b INTEGER
NOT
> NULL, c TIMESTAMP NOT NULL, d INTEGER NOT NULL ) ON COMMIT DROP
1.4 seconds is not great for create table, is that what we expect ?
> 0.450 ms INSERT INTO tmp SELECT * FROM bookmarks ORDER BY annonce_id
DESC
> LIMIT 20
> 0.443 ms ANALYZE tmp
> 0.365 ms SELECT * FROM tmp
> 0.310 ms DROP TABLE tmp
> 32.918 ms COMMIT
>
> CREATING the table is OK, but what happens on COMMIT ? I hear
the disk
> seeking frantically.
The 32 seconds for commit can hardly be catalog related. It seems the
file is
fsynced before it is dropped.
Andreas
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
!DSPAM:446c0a75172664042098162!
