1. 19 6月, 2000 4 次提交
    • T
      Clean up bogosities in pg_opclass, pg_amop, pg_amproc. There are amproc · c590273f
      Tom Lane 提交于
      entries now for int8 and network hash indexes.  int24_ops and int42_ops
      are gone.  pg_opclass no longer contains multiple entries claiming to be
      the default opclass for the same datatype.  opr_sanity regress test
      extended to catch errors like these in the future.
      c590273f
    • B
      Linux/alpha patch. · a53dc5ee
      Bruce Momjian 提交于
      a53dc5ee
    • T
      Reimplement nodeMaterial to use a temporary BufFile (or even memory, if the · 1ee26b77
      Tom Lane 提交于
      materialized tupleset is small enough) instead of a temporary relation.
      This was something I was thinking of doing anyway for performance, and Jan
      says he needs it for TOAST because he doesn't want to cope with toasting
      noname relations.  With this change, the 'noname table' support in heap.c
      is dead code, and I have accordingly removed it.  Also clean up 'noname'
      plan handling in planner --- nonames are either sort or materialize plans,
      and it seems less confusing to handle them separately under those names.
      1ee26b77
    • P
      Separated set constraints and set transaction reference pages, revised set · 2c0edb3c
      Peter Eisentraut 提交于
      reference page to new configuration system. Big update to administrator's
      guide, chapters Runtime environment, Client authentication, and User
      management, the latter two were part of the old Security chapter.
      2c0edb3c
  2. 18 6月, 2000 3 次提交
    • T
      Reinstate BufFileTell(). · b4e906f1
      Tom Lane 提交于
      b4e906f1
    • T
      Get rid of IndexIsUniqueNoCache() kluge by the simple expedient of · edf0b5f0
      Tom Lane 提交于
      passing the index-is-unique flag to index build routines (duh! ...
      why wasn't it done this way to begin with?).  Aside from eliminating
      an eyesore, this should save a few milliseconds in btree index creation
      because a full scan of pg_index is not needed any more.
      edf0b5f0
    • T
      Fix performance problems with pg_index lookups (see, for example, · d03a933e
      Tom Lane 提交于
      discussion of 5/19/00).  pg_index is now searched for indexes of a
      relation using an indexscan.  Moreover, this is done once and cached
      in the relcache entry for the relation, in the form of a list of OIDs
      for the indexes.  This list is used by the parser and executor to drive
      lookups in the pg_index syscache when they want to know the properties
      of the indexes.  Net result: index information will be fully cached
      for repetitive operations such as inserts.
      d03a933e
  3. 17 6月, 2000 3 次提交
  4. 16 6月, 2000 4 次提交
  5. 15 6月, 2000 12 次提交
  6. 14 6月, 2000 12 次提交
  7. 13 6月, 2000 2 次提交