| From: | Kyle Gearhart <kyle(dot)gearhart(at)indigohill(dot)io> |
|---|---|
| To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: libpq Alternate Row Processor |
| Date: | 2017-02-13 14:46:26 |
| Message-ID: | BLUPR14MB0162956D2C5887B726D5A7F8FA590@BLUPR14MB0162.namprd14.prod.outlook.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2/9/17 7:15 PM, Jim Nasby wrote:
> Can you run a trace to see where all the time is going in the single row case? I don't see an obvious time-suck with a quick look through the code. It'd be interesting to see how things change if you eliminate the filler column from the SELECT.
Traces are attached, these are with callgrind.
profile_nofiller.txt: single row without filler column
profile_filler.txt: single row with filler column
profile_filler_callback.txt: callback with filler column
pqResultAlloc looks to hit malloc pretty hard. The callback reduces all of that to a single malloc for each row.
Without the filler, here is the average over 11 runs:
Real user sys
Callback .133 .033 .035
Single Row .170 .112 .029
For the callback case, it's slightly higher than the prior results with the filler column.
| Attachment | Content-Type | Size |
|---|---|---|
| profile_nofiller.txt | text/plain | 2.7 KB |
| profile_filler.txt | text/plain | 2.8 KB |
| profile_filler_callback.txt | text/plain | 1.7 KB |
| Performance Results.xlsx | application/vnd.openxmlformats-officedocument.spreadsheetml.sheet | 11.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2017-02-13 15:22:09 | Re: Write Ahead Logging for Hash Indexes |
| Previous Message | Bernd Helmle | 2017-02-13 14:16:35 | Re: LWLock optimization for multicore Power machines |