"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
