Re: 27 second plan times

"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