1. 27 Aug, 2021 1 commit
    • Tom Lane's avatar
      Count SP-GiST index scans in pg_stat statistics. · e84d4810
      Tom Lane authored
      Somehow, spgist overlooked the need to call pgstat_count_index_scan().
      Hence, pg_stat_all_indexes.idx_scan and equivalent columns never
      became nonzero for an SP-GiST index, although the related per-tuple
      counters worked fine.
      
      This fix works a bit differently from other index AMs, in that the
      counter increment occurs in spgrescan not spggettuple/spggetbitmap.
      It looks like this won't make the user-visible semantics noticeably
      different, so I won't go to the trouble of introducing an is-this-
      the-first-call flag just to make the counter bumps happen in the
      same places.
      
      Per bug #17163 from Christian Quest.  Back-patch to all supported
      versions.
      
      Discussion: https://postgr.es/m/17163-b8c5cc88322a5e92@postgresql.org
      e84d4810
  2. 05 Apr, 2021 1 commit
  3. 04 Apr, 2021 2 commits
    • Tom Lane's avatar
      Fix more confusion in SP-GiST. · dfc843d4
      Tom Lane authored
      spg_box_quad_leaf_consistent unconditionally returned the leaf
      datum as leafValue, even though in its usage for poly_ops that
      value is of completely the wrong type.
      
      In versions before 12, that was harmless because the core code did
      nothing with leafValue in non-index-only scans ... but since commit
      2a636834, if we were doing a KNN-style scan, spgNewHeapItem would
      unconditionally try to copy the value using the wrong datatype
      parameters.  Said copying is a waste of time and space if we're not
      going to return the data, but it accidentally failed to fail until
      I fixed the datatype confusion in ac9099fc.
      
      Hence, change spgNewHeapItem to not copy the datum unless we're
      actually going to return it later.  This saves cycles and dodges
      the question of whether lossy opclasses are returning the right
      type.  Also change spg_box_quad_leaf_consistent to not return
      data that might be of the wrong type, as insurance against
      somebody introducing a similar bug into the core code in future.
      
      It seems like a good idea to back-patch these two changes into
      v12 and v13, although I'm afraid to change spgNewHeapItem's
      mistaken idea of which datatype to use in those branches.
      
      Per buildfarm results from ac9099fc.
      
      Discussion: https://postgr.es/m/3728741.1617381471@sss.pgh.pa.us
      dfc843d4
    • Tom Lane's avatar
      Fix confusion in SP-GiST between attribute type and leaf storage type. · ac9099fc
      Tom Lane authored
      According to the documentation, the attType passed to the opclass
      config function (and also relied on by the core code) is the type
      of the heap column or expression being indexed.  But what was
      actually being passed was the type stored for the index column.
      This made no difference for user-defined SP-GiST opclasses,
      because we weren't allowing the STORAGE clause of CREATE OPCLASS
      to be used, so the two types would be the same.  But it's silly
      not to allow that, seeing that the built-in poly_ops opclass
      has a different value for opckeytype than opcintype, and that if you
      want to do lossy storage then the types must really be different.
      (Thus, user-defined opclasses doing lossy storage had to lie about
      what type is in the index.)  Hence, remove the restriction, and make
      sure that we use the input column type not opckeytype where relevant.
      
      For reasons of backwards compatibility with existing user-defined
      opclasses, we can't quite insist that the specified leafType match
      the STORAGE clause; instead just add an amvalidate() warning if
      they don't match.
      
      Also fix some bugs that would only manifest when trying to return
      index entries when attType is different from attLeafType.  It's not
      too surprising that these have not been reported, because the only
      usual reason for such a difference is to store the leaf value
      lossily, rendering index-only scans impossible.
      
      Add a src/test/modules module to exercise cases where attType is
      different from attLeafType and yet index-only scan is supported.
      
      Discussion: https://postgr.es/m/3728741.1617381471@sss.pgh.pa.us
      ac9099fc
  4. 02 Jan, 2021 1 commit
  5. 30 Jan, 2020 1 commit
    • Alvaro Herrera's avatar
      Clean up newlines following left parentheses · c9d29775
      Alvaro Herrera authored
      We used to strategically place newlines after some function call left
      parentheses to make pgindent move the argument list a few chars to the
      left, so that the whole line would fit under 80 chars.  However,
      pgindent no longer does that, so the newlines just made the code
      vertically longer for no reason.  Remove those newlines, and reflow some
      of those lines for some extra naturality.
      
      Reviewed-by: Michael Paquier, Tom Lane
      Discussion: https://postgr.es/m/20200129200401.GA6303@alvherre.pgsql
      c9d29775
  6. 01 Jan, 2020 1 commit
  7. 26 Dec, 2019 1 commit
  8. 25 Dec, 2019 1 commit
    • Michael Paquier's avatar
      Rename files and headers related to index AM · 8ce3aa9b
      Michael Paquier authored
      The following renaming is done so as source files related to index
      access methods are more consistent with table access methods (the
      original names used for index AMs ware too generic, and could be
      confused as including features related to table AMs):
      - amapi.h -> indexam.h.
      - amapi.c -> indexamapi.c.  Here we have an equivalent with
      backend/access/table/tableamapi.c.
      - amvalidate.c -> indexamvalidate.c.
      - amvalidate.h -> indexamvalidate.h.
      - genam.c -> indexgenam.c.
      - genam.h -> indexgenam.h.
      
      This has been discussed during the development of v12 when table AM was
      worked on, but the renaming never happened.
      
      Author: Michael Paquier
      Reviewed-by: Fabien Coelho, Julien Rouhaud
      Discussion: https://postgr.es/m/20191223053434.GF34339@paquier.xyz
      8ce3aa9b
  9. 24 Sep, 2019 1 commit
  10. 19 Sep, 2019 1 commit
    • Alexander Korotkov's avatar
      Improve handling of NULLs in KNN-GiST and KNN-SP-GiST · 6cae9d2c
      Alexander Korotkov authored
      This commit improves subject in two ways:
      
       * It removes ugliness of 02f90879, which stores distance values and null
         flags in two separate arrays after GISTSearchItem struct.  Instead we pack
         both distance value and null flag in IndexOrderByDistance struct.  Alignment
         overhead should be negligible, because we typically deal with at most few
         "col op const" expressions in ORDER BY clause.
       * It fixes handling of "col op NULL" expression in KNN-SP-GiST.  Now, these
         expression are not passed to support functions, which can't deal with them.
         Instead, NULL result is implicitly assumed.  It future we may decide to
         teach support functions to deal with NULL arguments, but current solution is
         bugfix suitable for backpatch.
      
      Reported-by: Nikita Glukhov
      Discussion: https://postgr.es/m/826f57ee-afc7-8977-c44c-6111d18b02ec%40postgrespro.ru
      Author: Nikita Glukhov
      Reviewed-by: Alexander Korotkov
      Backpatch-through: 9.4
      6cae9d2c
  11. 08 Sep, 2019 1 commit
  12. 22 Jul, 2019 1 commit
  13. 16 Jul, 2019 1 commit
  14. 22 May, 2019 1 commit
  15. 11 Mar, 2019 1 commit
    • Andres Freund's avatar
      tableam: Add and use scan APIs. · c2fe139c
      Andres Freund authored
      Too allow table accesses to be not directly dependent on heap, several
      new abstractions are needed. Specifically:
      
      1) Heap scans need to be generalized into table scans. Do this by
         introducing TableScanDesc, which will be the "base class" for
         individual AMs. This contains the AM independent fields from
         HeapScanDesc.
      
         The previous heap_{beginscan,rescan,endscan} et al. have been
         replaced with a table_ version.
      
         There's no direct replacement for heap_getnext(), as that returned
         a HeapTuple, which is undesirable for a other AMs. Instead there's
         table_scan_getnextslot().  But note that heap_getnext() lives on,
         it's still used widely to access catalog tables.
      
         This is achieved by new scan_begin, scan_end, scan_rescan,
         scan_getnextslot callbacks.
      
      2) The portion of parallel scans that's shared between backends need
         to be able to do so without the user doing per-AM work. To achieve
         that new parallelscan_{estimate, initialize, reinitialize}
         callbacks are introduced, which operate on a new
         ParallelTableScanDesc, which again can be subclassed by AMs.
      
         As it is likely that several AMs are going to be block oriented,
         block oriented callbacks that can be shared between such AMs are
         provided and used by heap. table_block_parallelscan_{estimate,
         intiialize, reinitialize} as callbacks, and
         table_block_parallelscan_{nextpage, init} for use in AMs. These
         operate on a ParallelBlockTableScanDesc.
      
      3) Index scans need to be able to access tables to return a tuple, and
         there needs to be state across individual accesses to the heap to
         store state like buffers. That's now handled by introducing a
         sort-of-scan IndexFetchTable, which again is intended to be
         subclassed by individual AMs (for heap IndexFetchHeap).
      
         The relevant callbacks for an AM are index_fetch_{end, begin,
         reset} to create the necessary state, and index_fetch_tuple to
         retrieve an indexed tuple.  Note that index_fetch_tuple
         implementations need to be smarter than just blindly fetching the
         tuples for AMs that have optimizations similar to heap's HOT - the
         currently alive tuple in the update chain needs to be fetched if
         appropriate.
      
         Similar to table_scan_getnextslot(), it's undesirable to continue
         to return HeapTuples. Thus index_fetch_heap (might want to rename
         that later) now accepts a slot as an argument. Core code doesn't
         have a lot of call sites performing index scans without going
         through the systable_* API (in contrast to loads of heap_getnext
         calls and working directly with HeapTuples).
      
         Index scans now store the result of a search in
         IndexScanDesc->xs_heaptid, rather than xs_ctup->t_self. As the
         target is not generally a HeapTuple anymore that seems cleaner.
      
      To be able to sensible adapt code to use the above, two further
      callbacks have been introduced:
      
      a) slot_callbacks returns a TupleTableSlotOps* suitable for creating
         slots capable of holding a tuple of the AMs
         type. table_slot_callbacks() and table_slot_create() are based
         upon that, but have additional logic to deal with views, foreign
         tables, etc.
      
         While this change could have been done separately, nearly all the
         call sites that needed to be adapted for the rest of this commit
         also would have been needed to be adapted for
         table_slot_callbacks(), making separation not worthwhile.
      
      b) tuple_satisfies_snapshot checks whether the tuple in a slot is
         currently visible according to a snapshot. That's required as a few
         places now don't have a buffer + HeapTuple around, but a
         slot (which in heap's case internally has that information).
      
      Additionally a few infrastructure changes were needed:
      
      I) SysScanDesc, as used by systable_{beginscan, getnext} et al. now
         internally uses a slot to keep track of tuples. While
         systable_getnext() still returns HeapTuples, and will so for the
         foreseeable future, the index API (see 1) above) now only deals with
         slots.
      
      The remainder, and largest part, of this commit is then adjusting all
      scans in postgres to use the new APIs.
      
      Author: Andres Freund, Haribabu Kommi, Alvaro Herrera
      Discussion:
          https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
          https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
      c2fe139c
  16. 02 Jan, 2019 1 commit
  17. 31 Oct, 2018 1 commit
    • Tom Lane's avatar
      Fix memory leak in repeated SPGIST index scans. · 696b0c5f
      Tom Lane authored
      spgendscan neglected to pfree all the memory allocated by spgbeginscan.
      It's possible to get away with that in most normal queries, since the
      memory is allocated in the executor's per-query context which is about
      to get deleted anyway; but it causes severe memory leakage during
      creation or filling of large exclusion-constraint indexes.
      
      Also, document that amendscan is supposed to free what ambeginscan
      allocates.  The docs' lack of clarity on that point probably caused this
      bug to begin with.  (There is discussion of changing that API spec going
      forward, but I don't think it'd be appropriate for the back branches.)
      
      Per report from Bruno Wolff.  It's been like this since the beginning,
      so back-patch to all active branches.
      
      In HEAD, also fix an independent leak caused by commit 2a636834
      (allocating memory during spgrescan instead of spgbeginscan, which
      might be all right if it got cleaned up, but it didn't).  And do a bit
      of code beautification on that commit, too.
      
      Discussion: https://postgr.es/m/20181024012314.GA27428@wolff.to
      696b0c5f
  18. 18 Sep, 2018 1 commit
    • Alexander Korotkov's avatar
      Add support for nearest-neighbor (KNN) searches to SP-GiST · 2a636834
      Alexander Korotkov authored
      Currently, KNN searches were supported only by GiST.  SP-GiST also capable to
      support them.  This commit implements that support.  SP-GiST scan stack is
      replaced with queue, which serves as stack if no ordering is specified.  KNN
      support is provided for three SP-GIST opclasses: quad_point_ops, kd_point_ops
      and poly_ops (catversion is bumped).  Some common parts between GiST and SP-GiST
      KNNs are extracted into separate functions.
      
      Discussion: https://postgr.es/m/570825e8-47d0-4732-2bf6-88d67d2d51c8%40postgrespro.ru
      Author: Nikita Glukhov, Alexander Korotkov based on GSoC work by Vlad Sterzhanov
      Review: Andrey Borodin, Alexander Korotkov
      2a636834
  19. 11 Sep, 2018 1 commit
    • Andrew Gierth's avatar
      Repair double-free in SP-GIST rescan (bug #15378) · 500d4979
      Andrew Gierth authored
      spgrescan would first reset traversalCxt, and then traverse a
      potentially non-empty stack containing pointers to traversalValues
      which had been allocated in those contexts, freeing them a second
      time. This bug originates in commit ccd6eb49 where traversalValue was
      introduced.
      
      Repair by traversing the stack before the context reset; this isn't
      ideal, since it means doing retail pfree in a context that's about to
      be reset, but the freeing of a stack entry is also done in other
      places in the code during the scan so it's not worth trying to
      refactor it further. Regression test added.
      
      Backpatch to 9.6 where the problem was introduced.
      
      Per bug #15378; analysis and patch by me, originally from a report on
      IRC by user velix; see also PostGIS ticket #4174; review by Alexander
      Korotkov.
      
      Discussion: https://postgr.es/m/153663176628.23136.11901365223750051490@wrigleys.postgresql.org
      500d4979
  20. 20 Mar, 2018 1 commit
    • Tom Lane's avatar
      Prevent query-lifespan memory leakage of SP-GiST traversal values. · 467963c3
      Tom Lane authored
      The original coding of the SP-GiST scan traversalValue feature (commit
      ccd6eb49) arranged for traversal values to be stored in the query's main
      executor context.  That's fine if there's only one index scan per query,
      but if there are many, we have a memory leak as successive scans create
      new traversal values.  Fix it by creating a separate memory context for
      traversal values, which we can reset during spgrescan().  Back-patch
      to 9.6 where this code was introduced.
      
      In principle, adding the traversalCxt field to SpGistScanOpaqueData
      creates an ABI break in the back branches.  But I (tgl) have little
      sympathy for extensions including spgist_private.h, so I'm not very
      worried about that.  Alternatively we could stick the new field at the
      end of the struct in back branches, but that has its own downsides.
      
      Anton Dignös, reviewed by Alexander Kuzmenkov
      
      Discussion: https://postgr.es/m/CALNdv1jb6y2Te-m8xHLxLX12RsBmZJ1f4hESX7J0HjgyOhA9eA@mail.gmail.com
      467963c3
  21. 03 Jan, 2018 1 commit
  22. 22 Dec, 2017 1 commit
  23. 21 Jun, 2017 3 commits
    • Tom Lane's avatar
      Phase 3 of pgindent updates. · 382ceffd
      Tom Lane authored
      Don't move parenthesized lines to the left, even if that means they
      flow past the right margin.
      
      By default, BSD indent lines up statement continuation lines that are
      within parentheses so that they start just to the right of the preceding
      left parenthesis.  However, traditionally, if that resulted in the
      continuation line extending to the right of the desired right margin,
      then indent would push it left just far enough to not overrun the margin,
      if it could do so without making the continuation line start to the left of
      the current statement indent.  That makes for a weird mix of indentations
      unless one has been completely rigid about never violating the 80-column
      limit.
      
      This behavior has been pretty universally panned by Postgres developers.
      Hence, disable it with indent's new -lpl switch, so that parenthesized
      lines are always lined up with the preceding left paren.
      
      This patch is much less interesting than the first round of indent
      changes, but also bulkier, so I thought it best to separate the effects.
      
      Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
      Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
      382ceffd
    • Tom Lane's avatar
      Phase 2 of pgindent updates. · c7b8998e
      Tom Lane authored
      Change pg_bsd_indent to follow upstream rules for placement of comments
      to the right of code, and remove pgindent hack that caused comments
      following #endif to not obey the general rule.
      
      Commit e3860ffa wasn't actually using
      the published version of pg_bsd_indent, but a hacked-up version that
      tried to minimize the amount of movement of comments to the right of
      code.  The situation of interest is where such a comment has to be
      moved to the right of its default placement at column 33 because there's
      code there.  BSD indent has always moved right in units of tab stops
      in such cases --- but in the previous incarnation, indent was working
      in 8-space tab stops, while now it knows we use 4-space tabs.  So the
      net result is that in about half the cases, such comments are placed
      one tab stop left of before.  This is better all around: it leaves
      more room on the line for comment text, and it means that in such
      cases the comment uniformly starts at the next 4-space tab stop after
      the code, rather than sometimes one and sometimes two tabs after.
      
      Also, ensure that comments following #endif are indented the same
      as comments following other preprocessor commands such as #else.
      That inconsistency turns out to have been self-inflicted damage
      from a poorly-thought-through post-indent "fixup" in pgindent.
      
      This patch is much less interesting than the first round of indent
      changes, but also bulkier, so I thought it best to separate the effects.
      
      Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
      Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
      c7b8998e
    • Tom Lane's avatar
      Initial pgindent run with pg_bsd_indent version 2.0. · e3860ffa
      Tom Lane authored
      The new indent version includes numerous fixes thanks to Piotr Stefaniak.
      The main changes visible in this commit are:
      
      * Nicer formatting of function-pointer declarations.
      * No longer unexpectedly removes spaces in expressions using casts,
        sizeof, or offsetof.
      * No longer wants to add a space in "struct structname *varname", as
        well as some similar cases for const- or volatile-qualified pointers.
      * Declarations using PG_USED_FOR_ASSERTS_ONLY are formatted more nicely.
      * Fixes bug where comments following declarations were sometimes placed
        with no space separating them from the code.
      * Fixes some odd decisions for comments following case labels.
      * Fixes some cases where comments following code were indented to less
        than the expected column 33.
      
      On the less good side, it now tends to put more whitespace around typedef
      names that are not listed in typedefs.list.  This might encourage us to
      put more effort into typedef name collection; it's not really a bug in
      indent itself.
      
      There are more changes coming after this round, having to do with comment
      indentation and alignment of lines appearing within parentheses.  I wanted
      to limit the size of the diffs to something that could be reviewed without
      one's eyes completely glazing over, so it seemed better to split up the
      changes as much as practical.
      
      Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
      Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
      e3860ffa
  24. 27 Feb, 2017 1 commit
    • Tom Lane's avatar
      Allow index AMs to return either HeapTuple or IndexTuple format during IOS. · 9b88f27c
      Tom Lane authored
      Previously, only IndexTuple format was supported for the output data of
      an index-only scan.  This is fine for btree, which is just returning a
      verbatim index tuple anyway.  It's not so fine for SP-GiST, which can
      return reconstructed data that's much larger than a page.
      
      To fix, extend the index AM API so that index-only scan data can be
      returned in either HeapTuple or IndexTuple format.  There's other ways
      we could have done it, but this way avoids an API break for index AMs
      that aren't concerned with the issue, and it costs little except a couple
      more fields in IndexScanDescs.
      
      I changed both GiST and SP-GiST to use the HeapTuple method.  I'm not
      very clear on whether GiST can reconstruct data that's too large for an
      IndexTuple, but that seems possible, and it's not much of a code change to
      fix.
      
      Per a complaint from Vik Fearing.  Reviewed by Jason Li.
      
      Discussion: https://postgr.es/m/49527f79-530d-0bfe-3dad-d183596afa92@2ndquadrant.fr
      9b88f27c
  25. 03 Jan, 2017 1 commit
  26. 27 Aug, 2016 1 commit
    • Tom Lane's avatar
      Add macros to make AllocSetContextCreate() calls simpler and safer. · ea268cdc
      Tom Lane authored
      I found that half a dozen (nearly 5%) of our AllocSetContextCreate calls
      had typos in the context-sizing parameters.  While none of these led to
      especially significant problems, they did create minor inefficiencies,
      and it's now clear that expecting people to copy-and-paste those calls
      accurately is not a great idea.  Let's reduce the risk of future errors
      by introducing single macros that encapsulate the common use-cases.
      Three such macros are enough to cover all but two special-purpose contexts;
      those two calls can be left as-is, I think.
      
      While this patch doesn't in itself improve matters for third-party
      extensions, it doesn't break anything for them either, and they can
      gradually adopt the simplified notation over time.
      
      In passing, change TopMemoryContext to use the default allocation
      parameters.  Formerly it could only be extended 8K at a time.  That was
      probably reasonable when this code was written; but nowadays we create
      many more contexts than we did then, so that it's not unusual to have a
      couple hundred K in TopMemoryContext, even without considering various
      dubious code that sticks other things there.  There seems no good reason
      not to let it use growing blocks like most other contexts.
      
      Back-patch to 9.6, mostly because that's still close enough to HEAD that
      it's easy to do so, and keeping the branches in sync can be expected to
      avoid some future back-patching pain.  The bugs fixed by these changes
      don't seem to be significant enough to justify fixing them further back.
      
      Discussion: <21072.1472321324@sss.pgh.pa.us>
      ea268cdc
  27. 20 Apr, 2016 1 commit
    • Kevin Grittner's avatar
      Revert no-op changes to BufferGetPage() · a343e223
      Kevin Grittner authored
      The reverted changes were intended to force a choice of whether any
      newly-added BufferGetPage() calls needed to be accompanied by a
      test of the snapshot age, to support the "snapshot too old"
      feature.  Such an accompanying test is needed in about 7% of the
      cases, where the page is being used as part of a scan rather than
      positioning for other purposes (such as DML or vacuuming).  The
      additional effort required for back-patching, and the doubt whether
      the intended benefit would really be there, have indicated it is
      best just to rely on developers to do the right thing based on
      comments and existing usage, as we do with many other conventions.
      
      This change should have little or no effect on generated executable
      code.
      
      Motivated by the back-patching pain of Tom Lane and Robert Haas
      a343e223
  28. 08 Apr, 2016 2 commits
    • Kevin Grittner's avatar
      Add the "snapshot too old" feature · 848ef42b
      Kevin Grittner authored
      This feature is controlled by a new old_snapshot_threshold GUC.  A
      value of -1 disables the feature, and that is the default.  The
      value of 0 is just intended for testing.  Above that it is the
      number of minutes a snapshot can reach before pruning and vacuum
      are allowed to remove dead tuples which the snapshot would
      otherwise protect.  The xmin associated with a transaction ID does
      still protect dead tuples.  A connection which is using an "old"
      snapshot does not get an error unless it accesses a page modified
      recently enough that it might not be able to produce accurate
      results.
      
      This is similar to the Oracle feature, and we use the same SQLSTATE
      and error message for compatibility.
      848ef42b
    • Kevin Grittner's avatar
      Modify BufferGetPage() to prepare for "snapshot too old" feature · 8b65cf4c
      Kevin Grittner authored
      This patch is a no-op patch which is intended to reduce the chances
      of failures of omission once the functional part of the "snapshot
      too old" patch goes in.  It adds parameters for snapshot, relation,
      and an enum to specify whether the snapshot age check needs to be
      done for the page at this point.  This initial patch passes NULL
      for the first two new parameters and BGP_NO_SNAPSHOT_TEST for the
      third.  The follow-on patch will change the places where the test
      needs to be made.
      8b65cf4c
  29. 30 Mar, 2016 1 commit
    • Teodor Sigaev's avatar
      Introduce traversalValue for SP-GiST scan · ccd6eb49
      Teodor Sigaev authored
      During scan sometimes it would be very helpful to know some information about
      parent node or all 	ancestor nodes. Right now reconstructedValue could be used
      but it's not a right usage of it (range opclass uses that).
      
      traversalValue is arbitrary piece of memory in separate MemoryContext while
      reconstructedVale should have the same type as indexed column.
      
      Subsequent patches for range opclass and quad4d tree will use it.
      
      Author: Alexander Lebedev, Teodor Sigaev
      ccd6eb49
  30. 18 Jan, 2016 1 commit
    • Tom Lane's avatar
      Restructure index access method API to hide most of it at the C level. · 65c5fcd3
      Tom Lane authored
      This patch reduces pg_am to just two columns, a name and a handler
      function.  All the data formerly obtained from pg_am is now provided
      in a C struct returned by the handler function.  This is similar to
      the designs we've adopted for FDWs and tablesample methods.  There
      are multiple advantages.  For one, the index AM's support functions
      are now simple C functions, making them faster to call and much less
      error-prone, since the C compiler can now check function signatures.
      For another, this will make it far more practical to define index access
      methods in installable extensions.
      
      A disadvantage is that SQL-level code can no longer see attributes
      of index AMs; in particular, some of the crosschecks in the opr_sanity
      regression test are no longer possible from SQL.  We've addressed that
      by adding a facility for the index AM to perform such checks instead.
      (Much more could be done in that line, but for now we're content if the
      amvalidate functions more or less replace what opr_sanity used to do.)
      We might also want to expose some sort of reporting functionality, but
      this patch doesn't do that.
      
      Alexander Korotkov, reviewed by Petr Jelínek, and rather heavily
      editorialized on by me.
      65c5fcd3
  31. 02 Jan, 2016 1 commit
  32. 24 May, 2015 1 commit
  33. 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
  34. 06 Jan, 2015 1 commit
  35. 06 May, 2014 1 commit
    • Bruce Momjian's avatar
      pgindent run for 9.4 · 0a783200
      Bruce Momjian authored
      This includes removing tabs after periods in C comments, which was
      applied to back branches, so this change should not effect backpatching.
      0a783200
  36. 07 Jan, 2014 1 commit