From: | "Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)at> |
---|---|
To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, "PFC" <lists(at)peufeu(dot)com> |
Cc: | "Greg Stark" <gsstark(at)mit(dot)edu>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-performance(at)postgresql(dot)org>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Big IN() clauses etc : feature proposal |
Date: | 2006-05-11 07:55:15 |
Message-ID: | E1539E0ED7043848906A8FF995BDA57901053F20@m0143.s-mxs.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Volkan YAZICI | 2006-05-11 08:25:30 | Re: intarray internals |
Previous Message | Marko Kreen | 2006-05-11 07:55:01 | Re: BEGIN inside transaction should be an error |
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2006-05-11 08:30:25 | Re: [HACKERS] Big IN() clauses etc : feature proposal |
Previous Message | PFC | 2006-05-11 07:05:56 | Re: Speed Up Offset and Limit Clause |