From: | Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Questions on printtup() |
Date: | 2006-01-05 22:31:16 |
Message-ID: | Pine.LNX.4.58.0601051700110.14756@josh.db |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I did some profiling related to printtup() by a simple libpq "SELECT *
test" program (revised from the libpq programing sample in document
without retriving the results). There are 260k or so records in table
test(i int).
/* original version - prepare tuple and send */
SELECT * TIMING: 0.63 sec
/* Prepare but not send
In printtup():
- pq_endmessage(&buf);
+ pfree(buf.data);
+ buf.data = NULL;
*/
SELECT * TIMING: 0.46 sec
/* No prepare no send
In ExecSelect():
- (*dest->receiveSlot) (slot, dest);
*/
SELECT * TIMING: 0.08 sec
So we spend a portion of time at preparing tuples in printtup() by
converting the tuple format to a network format. I am not quite familiar
with that part, so I wonder is it possible to try to send with original
tuple format with minimal preparing job (say handling toast) -- which
might increase the amount of data of network communication, but may reduce
the CPU on server side?
If this is not a non-starter, I am happy to look into details,
Regards,
Qingqing
From | Date | Subject | |
---|---|---|---|
Next Message | Qingqing Zhou | 2006-01-05 23:24:27 | Warm-up cache may have its virtue |
Previous Message | Tom Lane | 2006-01-05 22:16:54 | Re: catalog corruption bug |