| From: | Thom Brown <thom(at)linux(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: SendRowDescriptionMessage() is slow for queries with a lot of columns |
| Date: | 2017-09-15 21:05:35 |
| Message-ID: | CAA-aLv4W_JdOTtcPAdA+XazGvFPeS=4wD2xPsSbPTARfwFi+0w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 15 September 2017 at 19:23, Andres Freund <andres(at)anarazel(dot)de> wrote:
> Hi Thom,
>
> Thanks for taking a whack at this!
>
> On 2017-09-15 12:16:22 +0100, Thom Brown wrote:
>> I've run a fairly basic test with a table with 101 columns, selecting
>> a single row from the table and I get the following results:
>>
>>
>> Columns with 1-character names:
>>
>> master (80 jobs, 80 connections, 60 seconds):
>
> FWIW, I don't think it's useful to test this with a lot of concurrency -
> at that point you're likely saturating the machine with context switches
> etc. unless you have a lot of cores. As this is isn't related to
> concurrency I'd rather just check a single connection.
>
>
>> transaction type: /tmp/test.sql
>> scaling factor: 1
>> query mode: simple
>
> I think you'd need to use prepared statements / -M prepared to see
> benefits - when parsing statements for every execution the bottleneck is
> elsewhere (hello O(#available_columns * #selected_columns) in
> colNameToVar()).
Okay, I've retested it using a prepared statement executed 100,000
times (which selects a single row from a table with 101 columns, each
column is 42-43 characters long, and 2 rows in the table), and I get
the following:
master:
real 1m23.485s
user 1m2.800s
sys 0m1.200s
patched:
real 1m22.530s
user 1m2.860s
sys 0m1.140s
Not sure why I'm not seeing the gain.
Thom
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2017-09-15 21:23:59 | Re: Partition-wise join for join between (declaratively) partitioned tables |
| Previous Message | Nico Williams | 2017-09-15 21:03:35 | Re: COMMIT TRIGGERs, take n, implemented with CONSTRAINT TRIGGERS |