> Böszörményi Zoltán <[EMAIL PROTECTED]> writes: >> With PostgreSQL 8.1.4, I used this: > >> begin; >> select ... into temp myquery1; >> copy myquery1 to stdout csv delimiter '|'; >> rollback; > > The performance of this would doubtless vary a lot with the temp_buffers > setting. Did you try different values?
Yes, I did, but now checked back with 8.2CVS. The previously quoted result was achieved with temp_buffers = 1000 on both 8.1.4 and 8.2CVS. On 8.2CVS with temp_buffers = 4096, the 10 client case kills the machine with swapping, but the 3 client runtime with COPY(SELECT) went down to 2:41. The SELECT INTO TEMP case went down to 3:36. > It'd also be interesting to time the same way (with a temp table) in > devel. I don't remember whether we did any performance work on the > COPY CSV data path in this cycle, or whether that was all present in > 8.1. In any case it'd be worth proving that the COPY SELECT patch isn't > degrading performance of the copy-a-relation case. I will report back with that, say on Monday. In the meantime, I documented the COPY (SELECT) case and modified parser/analyze.c and tcop/utility.c so neither of them calls anything from under another directory. I think it's cleaner now. Also, I tried to implement more closely what printtup() does. Please, review. Best regards, Zoltán Böszörményi
pgsql-copyselect-7.patch.gz
Description: GNU Zip compressed data
---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster