"Tom Lane" <[EMAIL PROTECTED]> 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. [EMAIL PROTECTED]:/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_value 4.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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq