Re: [PERFORM] Big IN() clauses etc : feature proposal - Mailing list pgsql-hackers

From Gregory S. Williamson
Subject Re: [PERFORM] Big IN() clauses etc : feature proposal
Date
Msg-id 71E37EF6B7DCC1499CEA0316A2568328024BC4E5@loki.wc.globexplorer.net
Whole thread Raw
In response to Re: [PERFORM] Big IN() clauses etc : feature proposal  ("Zeugswetter Andreas DCP SD" <ZeugswetterA@spardat.at>)
List pgsql-hackers
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@postgresql.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@postgresql.org; pgsql-hackers@postgresql.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!





pgsql-hackers by date:

Previous
From: Michael Meskes
Date:
Subject: Re: Desperately Seeking Mentors -- Right Now!
Next
From: Florian Weimer
Date:
Subject: Re: [OT] MySQL is bad, but THIS bad?