1. 15 Jun, 2006 5 commits
    • Bruce Momjian's avatar
      Add: · fe8c1165
      Bruce Momjian authored
      >
      > 		o Fix memory leak from exceptions
      >
      > 		  http://archives.postgresql.org/pgsql-performance/2006-06/msg00305.php
      fe8c1165
    • Bruce Momjian's avatar
      Clarify dynamic pl/pgsql item and add URLs. Restructure server-side · 653fa217
      Bruce Momjian authored
      section into PL/pgSQL and non-PL/pgSQL sections:
      
      < 	o Fix PL/pgSQL RENAME to work on variables other than OLD/NEW
      < 	o Allow function parameters to be passed by name,
      < 	  get_employee_salary(emp_id => 12345, tax_year => 2001)
      < 	o Add Oracle-style packages
      < 	o Add table function support to pltcl, plpython
      < 	o Add capability to create and call PROCEDURES
      < 	o Allow PL/pgSQL to handle %TYPE arrays, e.g. tab.col%TYPE[]
      < 	o Allow function argument names to be statements from PL/PgSQL
      < 	o Add MOVE to PL/pgSQL
      < 	o Add support for polymorphic arguments and return types to
      < 	  languages other than PL/PgSQL
      < 	o Add support for OUT and INOUT parameters to languages other
      < 	  than PL/PgSQL
      < 	o Add single-step debugging of PL/PgSQL functions
      < 	o Allow PL/PgSQL to support WITH HOLD cursors
      < 	o Allow PL/PgSQL RETURN to return row or record functions
      <
      < 	  http://archives.postgresql.org/pgsql-patches/2005-11/msg00045.php
      > 	o PL/pgSQL
      > 		o Fix RENAME to work on variables other than OLD/NEW
      > 		o Allow function parameters to be passed by name,
      > 		  get_employee_salary(emp_id => 12345, tax_year => 2001)
      > 		o Add Oracle-style packages
      > 		o Allow handling of %TYPE arrays, e.g. tab.col%TYPE[]
      > 		o Allow listing of record column names, and access to
      > 		  record columns via variables, e.g. columns := r.(*),
      > 		  tval2 := r.(colname)
      >
      > 		  http://archives.postgresql.org/pgsql-patches/2005-07/msg00458.php
      > 		  http://archives.postgresql.org/pgsql-patches/2006-05/msg00302.php
      > 		  http://archives.postgresql.org/pgsql-patches/2006-06/msg00031.php
      >
      > 		o Add MOVE
      > 		o Add single-step debugging of functions
      > 		o Add support for WITH HOLD cursors
      > 		o Allow PL/RETURN to return row or record functions
      >
      > 		  http://archives.postgresql.org/pgsql-patches/2005-11/msg00045.php
      >
      >
      > 	o Other
      > 		o Add table function support to pltcl, plpython
      > 		o Add support for polymorphic arguments and return types to
      > 		  languages other than PL/PgSQL
      > 		o Add capability to create and call PROCEDURES
      > 		o Add support for OUT and INOUT parameters to languages other
      > 		  than PL/PgSQL
      653fa217
    • Bruce Momjian's avatar
      Add: · fce5033b
      Bruce Momjian authored
      > 	o Allow PL/PgSQL RETURN to return row or record functions
      >
      > 	  http://archives.postgresql.org/pgsql-patches/2005-11/msg00045.php
      fce5033b
    • Bruce Momjian's avatar
      Done, removed: · f8cdc265
      Bruce Momjian authored
      <
      < * Consider padding the spinlock structure to have spinlock registers
      <   on different CPU cache line
      <
      <   http://archives.postgresql.org/pgsql-hackers/2005-10/msg00498.php
      f8cdc265
    • Tom Lane's avatar
      Remove the limit on the number of entries allowed in catcaches, and · 8b9bc234
      Tom Lane authored
      remove the infrastructure needed to enforce the limit, ie, the global
      LRU list of cache entries.  On small-to-middling databases this wins
      because maintaining the LRU list is a waste of time.  On large databases
      this wins because it's better to keep more cache entries (we assume
      such users can afford to use some more per-backend memory than was
      contemplated in the Berkeley-era catcache design).  This provides a
      noticeable improvement in the speed of psql \d on a 10000-table
      database, though it doesn't make it instantaneous.
      
      While at it, use per-catcache settings for the number of hash buckets
      per catcache, rather than the former one-size-fits-all value.  It's a
      bit silly to be using the same number of hash buckets for, eg, pg_am
      and pg_attribute.  The specific values I used might need some tuning,
      but they seem to be in the right ballpark based on CATCACHE_STATS
      results from the standard regression tests.
      8b9bc234
  2. 14 Jun, 2006 27 commits
  3. 13 Jun, 2006 1 commit
  4. 12 Jun, 2006 6 commits
  5. 11 Jun, 2006 1 commit