"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> Applied along with some other hacking to reduce the costs of the
> lower-level functions that this example shows to be inefficient.
> They'd still be slow in large queries, whether CE applies or not.
BIG difference. The case that caused swapping and took almost 15m to plan is
now down to 2.5s. The profile still looks a bit odd but I can't argue with
the results.
stark@oxford:/var/tmp/db$ gprof /usr/local/pgsql/bin/postgres gmon.out
Flat profile:
Each sample counts as 0.01 seconds. % cumulative self self total time seconds
seconds calls s/call s/call name 24.36 2.46 2.46 418517 0.00 0.00 SearchCatCache 7.33
3.20 0.74 2564235 0.00 0.00 hash_any 6.34 3.84 0.64 4283964 0.00 0.00
hash_search_with_hash_value4.36 4.28 0.44 216316 0.00 0.00 list_nth_cell 3.96 4.68 0.40
6535943 0.00 0.00 AllocSetAlloc 3.37 5.02 0.34 4165664 0.00 0.00 _bt_compare 2.67 5.29
0.27 2266696 0.00 0.00 MemoryContextAllocZeroAligned
... 0.01 0.03 2000/424529 get_namespace_name [164] 0.01 0.03 2001/424529
pg_class_aclmask [167] 0.01 0.03 2001/424529 get_rel_name [163] 0.01 0.03
2002/424529 has_subclass [165] 1.21 2.69 204102/424529 get_attavgwidth [37]
1.21 2.69 204308/424529 TupleDescInitEntry [36]
[632] 0.0 0.00 0.00 418517 SearchSysCache <cycle 9> [632] 418517
SearchCatCache <cycle 9> [15]
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com