Re: [HACKERS] Big IN() clauses etc : feature proposal

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(at)postgresql(dot)org 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(at)postgresql(dot)org; pgsql-hackers(at)postgresql(dot)org
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!