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(at)2ndQuadrant(dot)com Baltimore, MD