Re: Single client performance on trivial SELECTs

Heikki Linnakangas wrote:
> In this case you could just use prepared statements and get rid of all 
> the parser related overhead, which includes much of the allocations.

Trying that gives me around 9200 TPS instead of 5500 on my laptop, so a 
pretty big gain here.  Will have to include that in my next round of 
graphs across multiple client loads once I'm home again and can run 
easily on my server.

To provide a matching profile from the same system as the one I already 
submitted from, for archival sake, here's what the profile I get looks 
like with "-M prepared":

samples  %        image name               symbol name
33093     4.8518  postgres                 AllocSetAlloc
30012     4.4001  postgres                 hash_seq_search
27149     3.9803  postgres                 MemoryContextAllocZeroAligned
26987     3.9566  postgres                 hash_search_with_hash_value
25665     3.7628  postgres                 hash_any
16820     2.4660  postgres                 _bt_compare
14778     2.1666  postgres                 LockAcquireExtended
12263     1.7979  postgres                 AllocSetFreeIndex
11727     1.7193  postgres                 tas
11602     1.7010  postgres                 SearchCatCache
11022     1.6159  postgres                 pg_encoding_mbcliplen
10963     1.6073  postgres                 MemoryContextAllocZero
9296      1.3629  postgres                 MemoryContextCreate
8368      1.2268  postgres                 fmgr_isbuiltin
7973      1.1689  postgres                 LockReleaseAll
7423      1.0883  postgres                 ExecInitExpr
7309      1.0716  postgres                 pfree

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD