On 15 September 2017 at 19:23, Andres Freund <and...@anarazel.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
