1. 04 Oct, 2021 1 commit
  2. 16 Jul, 2021 1 commit
  3. 30 Dec, 2020 1 commit
    • Tom Lane's avatar
      Doc: fix up PDF build warnings from over-width table columns. · f20dc2c8
      Tom Lane authored
      Addition of multirange info to tables 8.27 and 65.1 made them start
      throwing "exceed the available area" warnings in PDF docs builds.
      
      For 8.27, twiddling the existing column width hints was enough to
      fix this.  For 65.1, I twiddled the widths a little, but to really
      fix it I had to insert a space after each comma in the table, to
      allow a line break to occur there.  (This seemed easier to read
      and maintain than the alternative of inserting &zwsp; entities.)
      
      Per buildfarm.
      f20dc2c8
  4. 29 Dec, 2020 1 commit
    • Alexander Korotkov's avatar
      Add support of multirange matching to the existing range GiST indexes · db6335b5
      Alexander Korotkov authored
      6df7a969 has introduced a set of operators between ranges and multiranges.
      Existing GiST indexes for ranges could easily support majority of them.
      This commit adds support for new operators to the existing range GiST indexes.
      New operators resides the same strategy numbers as existing ones.  Appropriate
      check function is determined using the subtype.
      
      Catversion is bumped.
      db6335b5
  5. 23 Nov, 2020 1 commit
    • Tom Lane's avatar
      Rename the "point is strictly above/below point" comparison operators. · 0cc99327
      Tom Lane authored
      Historically these were called >^ and <^, but that is inconsistent
      with the similar box, polygon, and circle operators, which are named
      |>> and <<| respectively.  Worse, the >^ and <^ names are used for
      *not* strict above/below tests for the box type.
      
      Hence, invent new operators following the more common naming.  The
      old operators remain available for now, and are still accepted by
      the relevant index opclasses too.  But there's a deprecation notice,
      so maybe we can get rid of them someday.
      
      Emre Hasegeli, reviewed by Pavel Borisov
      
      Discussion: https://postgr.es/m/24348.1587444160@sss.pgh.pa.us
      0cc99327
  6. 12 Oct, 2020 1 commit
    • Tom Lane's avatar
      Re-allow testing of GiST buffered builds. · 78c0b6ed
      Tom Lane authored
      Commit 16fa9b2b broke the ability to reliably test GiST buffered builds,
      because it caused sorted builds to be done instead if sortsupport is
      available, regardless of any attempt to override that.  While a would-be
      test case could try to work around that by choosing an opclass that has
      no sortsupport function, coverage would be silently lost the moment
      someone decides it'd be a good idea to add a sortsupport function.
      
      Hence, rearrange the logic in gistbuild() so that if "buffering = on"
      is specified in CREATE INDEX, we will use that method, sortsupport or no.
      
      Also document the interaction between sorting and the buffering
      parameter, as 16fa9b2b failed to do.
      
      (Note that in fact we still lack any test coverage of buffered builds,
      but this is a prerequisite to adding a non-fragile test.)
      
      Discussion: https://postgr.es/m/3249980.1602532990@sss.pgh.pa.us
      78c0b6ed
  7. 17 Sep, 2020 1 commit
    • Heikki Linnakangas's avatar
      Add support for building GiST index by sorting. · 16fa9b2b
      Heikki Linnakangas authored
      This adds a new optional support function to the GiST access method:
      sortsupport. If it is defined, the GiST index is built by sorting all data
      to the order defined by the sortsupport's comparator function, and packing
      the tuples in that order to GiST pages. This is similar to how B-tree
      index build works, and is much faster than inserting the tuples one by
      one. The resulting index is smaller too, because the pages are packed more
      tightly, upto 'fillfactor'. The normal build method works by splitting
      pages, which tends to lead to more wasted space.
      
      The quality of the resulting index depends on how good the opclass-defined
      sort order is. A good order preserves locality of the input data.
      
      As the first user of this facility, add 'sortsupport' function to the
      point_ops opclass. It sorts the points in Z-order (aka Morton Code), by
      interleaving the bits of the X and Y coordinates.
      
      Author: Andrey Borodin
      Reviewed-by: Pavel Borisov, Thomas Munro
      Discussion: https://www.postgresql.org/message-id/1A36620E-CAD8-4267-9067-FB31385E7C0D%40yandex-team.ru
      16fa9b2b
  8. 28 Aug, 2020 1 commit
    • Michael Paquier's avatar
      doc: Rework tables for built-in operator classes of index AMs · 7a1cd526
      Michael Paquier authored
      The tables listing all the operator classes available for BRIN, GIN,
      GiST and SP-GiST had a confusing format where the same operator could be
      listed multiple times, for different data types.  This improves the
      shape of these tables by adding the types associated to each operator,
      for their associated operator class.
      
      Each table included previously the data type that could be used for an
      operator class in an extra column.  This is removed to reduce the width
      of the tables as this is now described within each operator.  This also
      makes the tables fit better in the PDF documentation.
      
      Reported-by: osdba
      Author: Michael Paquier
      Reviewed-by: Álvaro Herrera, Tom Lane, Bruce Momjian
      Discussion: https://postgr.es/m/38d55061.9604.173b32c60ec.Coremail.mailtch@163.com
      7a1cd526
  9. 24 Aug, 2020 1 commit
  10. 21 Jun, 2020 1 commit
  11. 20 Jun, 2020 1 commit
  12. 11 Jun, 2020 1 commit
  13. 15 May, 2020 1 commit
  14. 08 Sep, 2019 1 commit
  15. 19 Aug, 2019 1 commit
  16. 16 Jul, 2019 1 commit
  17. 14 Jul, 2019 1 commit
  18. 08 Jul, 2019 1 commit
  19. 23 Nov, 2017 1 commit
    • Peter Eisentraut's avatar
      Convert documentation to DocBook XML · 3c49c6fa
      Peter Eisentraut authored
      Since some preparation work had already been done, the only source
      changes left were changing empty-element tags like <xref linkend="foo">
      to <xref linkend="foo"/>, and changing the DOCTYPE.
      
      The source files are still named *.sgml, but they are actually XML files
      now.  Renaming could be considered later.
      
      In the build system, the intermediate step to convert from SGML to XML
      is removed.  Everything is build straight from the source files again.
      The OpenSP (or the old SP) package is no longer needed.
      
      The documentation toolchain instructions are updated and are much
      simpler now.
      
      Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
      3c49c6fa
  20. 20 Oct, 2017 1 commit
    • Peter Eisentraut's avatar
      Convert SGML IDs to lower case · 1ff01b39
      Peter Eisentraut authored
      IDs in SGML are case insensitive, and we have accumulated a mix of upper
      and lower case IDs, including different variants of the same ID.  In
      XML, these will be case sensitive, so we need to fix up those
      differences.  Going to all lower case seems most straightforward, and
      the current build process already makes all anchors and lower case
      anyway during the SGML->XML conversion, so this doesn't create any
      difference in the output right now.  A future XML-only build process
      would, however, maintain any mixed case ID spellings in the output, so
      that is another reason to clean this up beforehand.
      
      Author: Alexander Lakhin <exclusion@gmail.com>
      1ff01b39
  21. 17 Oct, 2017 1 commit
    • Peter Eisentraut's avatar
      Don't use SGML empty tags · c29c5789
      Peter Eisentraut authored
      For DocBook XML compatibility, don't use SGML empty tags (</>) anymore,
      replace by the full tag name.  Add a warning option to catch future
      occurrences.
      
      Alexander Lakhin, Jürgen Purtz
      c29c5789
  22. 20 Sep, 2017 1 commit
    • Tom Lane's avatar
      Allow no-op GiST support functions to be omitted. · d3a4f89d
      Tom Lane authored
      There are common use-cases in which the compress and/or decompress
      functions can be omitted, with the result being that we make no
      data transformation when storing or retrieving index values.
      Previously, you had to provide a no-op function anyway, but this
      patch allows such opclass support functions to be omitted.
      
      Furthermore, if the compress function is omitted, then the core code
      knows that the stored representation is the same as the original data.
      This means we can allow index-only scans without requiring a fetch
      function to be provided either.  Previously you had to provide a
      no-op fetch function if you wanted IOS to work.
      
      This reportedly provides a small performance benefit in such cases,
      but IMO the real reason for doing it is just to reduce the amount of
      useless boilerplate code that has to be written for GiST opclasses.
      
      Andrey Borodin, reviewed by Dmitriy Sarafannikov
      
      Discussion: https://postgr.es/m/CAJEAwVELVx9gYscpE=Be6iJxvdW5unZ_LkcAaVNSeOwvdwtD=A@mail.gmail.com
      d3a4f89d
  23. 19 Jan, 2016 1 commit
    • Tom Lane's avatar
      Fix assorted inconsistencies in GiST opclass support function declarations. · 9ff60273
      Tom Lane authored
      The conventions specified by the GiST SGML documentation were widely
      ignored.  For example, the strategy-number argument for "consistent" and
      "distance" functions is specified to be a smallint, but most of the
      built-in support functions declared it as an integer, and for that matter
      the core code passed it using Int32GetDatum not Int16GetDatum.  None of
      that makes any real difference at runtime, but it's quite confusing for
      newcomers to the code, and it makes it very hard to write an amvalidate()
      function that checks support function signatures.  So let's try to instill
      some consistency here.
      
      Another similar issue is that the "query" argument is not of a single
      well-defined type, but could have different types depending on the strategy
      (corresponding to search operators with different righthand-side argument
      types).  Some of the functions threw up their hands and declared the query
      argument as being of "internal" type, which surely isn't right ("any" would
      have been more appropriate); but the majority position seemed to be to
      declare it as being of the indexed data type, corresponding to a search
      operator with both input types the same.  So I've specified a convention
      that that's what to do always.
      
      Also, the result of the "union" support function actually must be of the
      index's storage type, but the documentation suggested declaring it to
      return "internal", and some of the functions followed that.  Standardize
      on telling the truth, instead.
      
      Similarly, standardize on declaring the "same" function's inputs as
      being of the storage type, not "internal".
      
      Also, somebody had forgotten to add the "recheck" argument to both
      the documentation of the "distance" support function and all of their
      SQL declarations, even though the C code was happily using that argument.
      Clean that up too.
      
      Fix up some other omissions in the docs too, such as documenting that
      union's second input argument is vestigial.
      
      So far as the errors in core function declarations go, we can just fix
      pg_proc.h and bump catversion.  Adjusting the erroneous declarations in
      contrib modules is more debatable: in principle any change in those
      scripts should involve an extension version bump, which is a pain.
      However, since these changes are purely cosmetic and make no functional
      difference, I think we can get away without doing that.
      9ff60273
  24. 24 May, 2015 1 commit
    • Tom Lane's avatar
      Remove no-longer-required function declarations. · 91e79260
      Tom Lane authored
      Remove a bunch of "extern Datum foo(PG_FUNCTION_ARGS);" declarations that
      are no longer needed now that PG_FUNCTION_INFO_V1(foo) provides that.
      
      Some of these were evidently missed in commit e7128e8d, but others
      were cargo-culted in in code added since then.  Possibly that can be blamed
      in part on the fact that we'd not fixed relevant documentation examples,
      which I've now done.
      91e79260
  25. 23 May, 2015 1 commit
  26. 15 May, 2015 3 commits
    • Bruce Momjian's avatar
      docs: consistently uppercase index method and add spacing · f6d65f0c
      Bruce Momjian authored
      Consistently uppercase index method names, e.g. GIN, and add space after
      the index method name and the parentheses enclosing the column names.
      f6d65f0c
    • Heikki Linnakangas's avatar
      Fix datatype confusion with the new lossy GiST distance functions. · 98edd617
      Heikki Linnakangas authored
      We can only support a lossy distance function when the distance function's
      datatype is comparable with the original ordering operator's datatype.
      The distance function always returns a float8, so we are limited to float8,
      and float4 (by a hard-coded cast of the float8 to float4).
      
      In light of this limitation, it seems like a good idea to have a separate
      'recheck' flag for the ORDER BY expressions, so that if you have a non-lossy
      distance function, it still works with lossy quals. There are cases like
      that with the build-in or contrib opclasses, but it's plausible.
      
      There was a hidden assumption that the ORDER BY values returned by GiST
      match the original ordering operator's return type, but there are plenty
      of examples where that's not true, e.g. in btree_gist and pg_trgm. As long
      as the distance function is not lossy, we can tolerate that and just not
      return the distance to the executor (or rather, always return NULL). The
      executor doesn't need the distances if there are no lossy results.
      
      There was another little bug: the recheck variable was not initialized
      before calling the distance function. That revealed the bigger issue,
      as the executor tried to reorder tuples that didn't need reordering, and
      that failed because of the datatype mismatch.
      98edd617
    • Heikki Linnakangas's avatar
      Allow GiST distance function to return merely a lower-bound. · 35fcb1b3
      Heikki Linnakangas authored
      The distance function can now set *recheck = false, like index quals. The
      executor will then re-check the ORDER BY expressions, and use a queue to
      reorder the results on the fly.
      
      This makes it possible to do kNN-searches on polygons and circles, which
      don't store the exact value in the index, but just a bounding box.
      
      Alexander Korotkov and me
      35fcb1b3
  27. 26 Mar, 2015 1 commit
    • Heikki Linnakangas's avatar
      Add support for index-only scans in GiST. · d04c8ed9
      Heikki Linnakangas authored
      This adds a new GiST opclass method, 'fetch', which is used to reconstruct
      the original Datum from the value stored in the index. Also, the 'canreturn'
      index AM interface function gains a new 'attno' argument. That makes it
      possible to use index-only scans on a multi-column index where some of the
      opclasses support index-only scans but some do not.
      
      This patch adds support in the box and point opclasses. Other opclasses
      can added later as follow-on patches (btree_gist would be particularly
      interesting).
      
      Anastasia Lubennikova, with additional fixes and modifications by me.
      d04c8ed9
  28. 28 Jan, 2015 1 commit
    • Heikki Linnakangas's avatar
      Remove dead NULL-pointer checks in GiST code. · 670bf71f
      Heikki Linnakangas authored
      gist_poly_compress() and gist_circle_compress() checked for a NULL-pointer
      key argument, but that was dead code; the gist code never passes a
      NULL-pointer to the "compress" method.
      
      This commit also removes a documentation note added in commit a0a3883d,
      about doing NULL-pointer checks in the "compress" method. It was added
      based on the fact that some implementations were doing NULL-pointer
      checks, but those checks were unnecessary in the first place.
      
      The NULL-pointer check in gbt_var_same() function was also unnecessary.
      The arguments to the "same" method come from the "compress", "union", or
      "picksplit" methods, but none of them return a NULL pointer.
      
      None of this is to be confused with SQL NULL values. Those are dealt with
      by the gist machinery, and are never passed to the GiST opclass methods.
      
      Michael Paquier
      670bf71f
  29. 11 Nov, 2014 1 commit
    • Fujii Masao's avatar
      Add GUC and storage parameter to set the maximum size of GIN pending list. · a1b395b6
      Fujii Masao authored
      Previously the maximum size of GIN pending list was controlled only by
      work_mem. But the reasonable value of work_mem and the reasonable size
      of the list are basically not the same, so it was not appropriate to
      control both of them by only one GUC, i.e., work_mem. This commit
      separates new GUC, pending_list_cleanup_size, from work_mem to allow
      users to control only the size of the list.
      
      Also this commit adds pending_list_cleanup_size as new storage parameter
      to allow users to specify the size of the list per index. This is useful,
      for example, when users want to increase the size of the list only for
      the GIN index which can be updated heavily, and decrease it otherwise.
      
      Reviewed by Etsuro Fujita.
      a1b395b6
  30. 08 Apr, 2014 1 commit
    • Tom Lane's avatar
      Add an in-core GiST index opclass for inet/cidr types. · f23a5630
      Tom Lane authored
      This operator class can accelerate subnet/supernet tests as well as
      btree-equivalent ordered comparisons.  It also handles a new network
      operator inet && inet (overlaps, a/k/a "is supernet or subnet of"),
      which is expected to be useful in exclusion constraints.
      
      Ideally this opclass would be the default for GiST with inet/cidr data,
      but we can't mark it that way until we figure out how to do a more or
      less graceful transition from the current situation, in which the
      really-completely-bogus inet/cidr opclasses in contrib/btree_gist are
      marked as default.  Having the opclass in core and not default is better
      than not having it at all, though.
      
      While at it, add new documentation sections to allow us to officially
      document GiST/GIN/SP-GiST opclasses, something there was never a clear
      place to do before.  I filled these in with some simple tables listing
      the existing opclasses and the operators they support, but there's
      certainly scope to put more information there.
      
      Emre Hasegeli, reviewed by Andreas Karlsson, further hacking by me
      f23a5630
  31. 07 Jun, 2012 1 commit
  32. 30 Sep, 2011 1 commit
    • Tom Lane's avatar
      Support GiST index support functions that want to cache data across calls. · d22a09dc
      Tom Lane authored
      pg_trgm was already doing this unofficially, but the implementation hadn't
      been thought through very well and leaked memory.  Restructure the core
      GiST code so that it actually works, and document it.  Ordinarily this
      would have required an extra memory context creation/destruction for each
      GiST index search, but I was able to avoid that in the normal case of a
      non-rescanned search by finessing the handling of the RBTree.  It used to
      have its own context always, but now shares a context with the
      scan-lifespan data structures, unless there is more than one rescan call.
      This should make the added overhead unnoticeable in typical cases.
      d22a09dc
  33. 08 Sep, 2011 1 commit
    • Heikki Linnakangas's avatar
      Buffering GiST index build algorithm. · 5edb24a8
      Heikki Linnakangas authored
      When building a GiST index that doesn't fit in cache, buffers are attached
      to some internal nodes in the index. This speeds up the build by avoiding
      random I/O that would otherwise be needed to traverse all the way down the
      tree to the find right leaf page for tuple.
      
      Alexander Korotkov
      5edb24a8
  34. 31 May, 2011 1 commit
    • Tom Lane's avatar
      Protect GIST logic that assumes penalty values can't be negative. · 6923d699
      Tom Lane authored
      Apparently sane-looking penalty code might return small negative values,
      for example because of roundoff error.  This will confuse places like
      gistchoose().  Prevent problems by clamping negative penalty values to
      zero.  (Just to be really sure, I also made it force NaNs to zero.)
      Back-patch to all supported branches.
      
      Alexander Korotkov
      6923d699
  35. 23 Dec, 2010 1 commit
    • Heikki Linnakangas's avatar
      Rewrite the GiST insertion logic so that we don't need the post-recovery · 9de3aa65
      Heikki Linnakangas authored
      cleanup stage to finish incomplete inserts or splits anymore. There was two
      reasons for the cleanup step:
      
      1. When a new tuple was inserted to a leaf page, the downlink in the parent
      needed to be updated to contain (ie. to be consistent with) the new key.
      Updating the parent in turn might require recursively updating the parent of
      the parent. We now handle that by updating the parent while traversing down
      the tree, so that when we insert the leaf tuple, all the parents are already
      consistent with the new key, and the tree is consistent at every step.
      
      2. When a page is split, we need to insert the downlink for the new right
      page(s), and update the downlink for the original page to not include keys
      that moved to the right page(s). We now handle that by setting a new flag,
      F_FOLLOW_RIGHT, on the non-rightmost pages in the split. When that flag is
      set, scans always follow the rightlink, regardless of the NSN mechanism used
      to detect concurrent page splits. That way the tree is consistent right after
      split, even though the downlink is still missing. This is very similar to the
      way B-tree splits are handled. When the downlink is inserted in the parent,
      the flag is cleared. To keep the insertion algorithm simple, when an
      insertion sees an incomplete split, indicated by the F_FOLLOW_RIGHT flag, it
      finishes the split before doing anything else.
      
      These changes allow removing the whole "invalid tuple" mechanism, but I
      retained the scan code to still follow invalid tuples correctly. While we
      don't create any such tuples anymore, we want to handle them gracefully in
      case you pg_upgrade a GiST index that has them. If we encounter any on an
      insert, though, we just throw an error saying that you need to REINDEX.
      
      The issue that got me into doing this is that if you did a checkpoint while
      an insert or split was in progress, and the checkpoint finishes quickly so
      that there is no WAL record related to the insert between RedoRecPtr and the
      checkpoint record, recovery from that checkpoint would not know to finish
      the incomplete insert. IOW, we have the same issue we solved with the
      rm_safe_restartpoint mechanism during normal operation too. It's highly
      unlikely to happen in practice, and this fix is far too large to backpatch,
      so we're just going to live with in previous versions, but this refactoring
      fixes it going forward.
      
      With this patch, you don't get the annoying
      'index "FOO" needs VACUUM or REINDEX to finish crash recovery' notices
      anymore if you crash at an unfortunate moment.
      9de3aa65
  36. 04 Dec, 2010 1 commit
  37. 20 Sep, 2010 1 commit
  38. 17 Aug, 2010 1 commit