| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
| Cc: | Zeugswetter Andreas DCP SD <ZeugswetterA(at)spardat(dot)at>, PFC <lists(at)peufeu(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, 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 22:08:36 |
| Message-ID: | 4335.1147385316@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
"Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
> I'd hope that wasn't what's happening... is the backend smart enough to
> know not to fsync anything involved with the temp table?
The catalog entries required for it have to be fsync'd, unless you enjoy
putting your entire database at risk (a bad block in pg_class, say,
would probably take out more than one table).
It's interesting to speculate about keeping such catalog entries in
child tables of pg_class etc that are themselves temp tables. Resolving
the apparent circularity of this is left as an exercise for the reader.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | spaminos-sql | 2006-05-11 22:35:47 | Querying libpq compile time options |
| Previous Message | Jim C. Nasby | 2006-05-11 21:56:03 | Re: Compressing table images |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim C. Nasby | 2006-05-11 22:19:28 | Re: [PERFORM] Arguments Pro/Contra Software Raid |
| Previous Message | Jim C. Nasby | 2006-05-11 22:08:02 | Re: Assistance with optimizing query - same SQL, different category_id = Seq Scan |