summaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistget.c
Commit message (Collapse)AuthorAgeFilesLines
...
* Update copyright notices for year 2012.Bruce Momjian2012-01-011-1/+1
|
* Support GiST index support functions that want to cache data across calls.Tom Lane2011-09-301-2/+2
| | | | | | | | | | | | 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.
* Remove unnecessary #include references, per pgrminclude script.Bruce Momjian2011-09-011-2/+0
|
* Move Trigger and TriggerDesc structs out of rel.h into a new reltrigger.hAlvaro Herrera2011-07-041-0/+1
| | | | | This lets us stop including rel.h into execnodes.h, which is a widely used header.
* Spell checking and markup refinementPeter Eisentraut2011-05-191-1/+1
|
* Pass collations to functions in FunctionCallInfoData, not FmgrInfo.Tom Lane2011-04-121-11/+13
| | | | | | | | | | | Since collation is effectively an argument, not a property of the function, FmgrInfo is really the wrong place for it; and this becomes critical in cases where a cached FmgrInfo is used for varying purposes that might need different collation settings. Fix by passing it in FunctionCallInfoData instead. In particular this allows a clean fix for bug #5970 (record_cmp not working). This requires touching a bit more code than the original method, but nobody ever thought that collations would not be an invasive patch...
* pgindent run before PG 9.1 beta 1.Bruce Momjian2011-04-101-11/+11
|
* Stamp copyrights for year 2011.Bruce Momjian2011-01-011-1/+1
|
* Rewrite the GiST insertion logic so that we don't need the post-recoveryHeikki Linnakangas2010-12-231-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fix two small bugs in new gistget.c logic.Tom Lane2010-12-041-1/+4
| | | | | | | | | | | | | 1. Complain, rather than silently doing nothing, if an "invalid" tuple is found on a leaf page. Per off-list discussion with Heikki. 2. Fix oversight in code that removes a GISTSearchItem from the search queue: we have to reset lastHeap if this was the last heap item in the parent GISTSearchTreeItem. Otherwise subsequent additions will do the wrong thing. This was probably masked in early testing because in typical cases the parent item would now be completely empty and would be deleted on next call. You'd need a queued non-leaf page at exactly the same distance as a heap tuple to expose the bug.
* Put back gistgettuple's check for backwards scan request.Tom Lane2010-12-031-0/+4
| | | | | On reflection it's a bad idea for the KNNGIST patch to have removed that. We don't want it silently returning incorrect answers.
* KNNGIST, otherwise known as order-by-operator support for GIST.Tom Lane2010-12-031-385/+434
| | | | | | | | | | | | | | | This commit represents a rather heavily editorialized version of Teodor's builtin_knngist_itself-0.8.2 and builtin_knngist_proc-0.8.1 patches. I redid the opclass API to add a separate Distance method instead of turning the Consistent method into an illogical mess, fixed some bit-rot in the rbtree interfaces, and generally worked over the code style and comments. There's still no non-code documentation to speak of, but I'll work on that separately. Some contrib-module changes are also yet to come (right now, point <-> point is the only KNN-ified operator). Teodor Sigaev and Tom Lane
* Remove cvs keywords from all files.Magnus Hagander2010-09-201-1/+1
|
* pgindent run for 9.0Bruce Momjian2010-02-261-2/+3
|
* Update copyright for the year 2010.Bruce Momjian2010-01-021-2/+2
|
* Support "x IS NOT NULL" clauses as indexscan conditions. This turns outTom Lane2010-01-011-8/+14
| | | | | | | | | | | to be just a minor extension of the previous patch that made "x IS NULL" indexable, because we can treat the IS NOT NULL condition as if it were "x < NULL" or "x > NULL" (depending on the index's NULLS FIRST/LAST option), just like IS NULL is treated like "x = NULL". Aside from any possible usefulness in its own right, this is an important improvement for index-optimized MAX/MIN aggregates: it is now reliably possible to get a column's min or max value cheaply, even when there are a lot of nulls cluttering the interesting end of the index.
* Remove very ancient tuple-counting infrastructure (IncrRetrieved() andTom Lane2009-10-081-3/+1
| | | | | | | | | friends). This code has all been ifdef'd out for many years, and doesn't seem to have any prospect of becoming any more useful in the future. EXPLAIN ANALYZE is what people use in practice, and I think if we did want process-wide counters we'd be more likely to put in dtrace events for that than try to resurrect this code. Get rid of it so as to have one less detail to worry about while refactoring execMain.c.
* 8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef listBruce Momjian2009-06-111-29/+29
| | | | provided by Andrew.
* Update copyright for 2009.Bruce Momjian2009-01-011-2/+2
|
* Fix GiST's killing tuple: GISTScanOpaque->curpos wasn'tTeodor Sigaev2008-10-221-19/+27
| | | | | | correctly set. As result, killtuple() marks as dead wrong tuple on page. Bug was introduced by me while fixing possible duplicates during GiST index scan.
* Remove support of backward scan in GiST. Per discussionTeodor Sigaev2008-10-201-25/+15
| | | | http://archives.postgresql.org/pgsql-hackers/2008-10/msg00857.php
* Remove mark/restore support in GIN and GiST indexes.Teodor Sigaev2008-10-201-11/+1
| | | | | Per Tom's comment. Also revome useless GISTScanOpaque->flags field.
* During repeated rescan of GiST index it's possible that scan keyTeodor Sigaev2008-10-171-1/+4
| | | | | | | | | is NULL but SK_SEARCHNULL is not set. Add checking IS NULL of keys to set during key initialization. If key is NULL and SK_SEARCHNULL is not set then nothnig can be satisfied. With assert-enabled compilation that causes coredump. Bug was introduced in 8.3 by support of IS NULL index scan.
* Fix possible duplicate tuples while GiST scan. Now page is processedTeodor Sigaev2008-08-231-89/+101
| | | | | | | | | at once and ItemPointers are collected in memory. Remove tuple's killing by killtuple() if tuple was moved to another page - it could produce unaceptable overhead. Backpatch up to 8.1 because the bug was introduced by GiST's concurrency support.
* Improve our #include situation by moving pointer types away from theAlvaro Herrera2008-06-191-1/+2
| | | | | | | corresponding struct definitions. This allows other headers to avoid including certain highly-loaded headers such as rel.h and relscan.h, instead using just relcache.h, heapam.h or genam.h, which are more lightweight and thus cause less unnecessary dependencies.
* Restructure some header files a bit, in particular heapam.h, by removing someAlvaro Herrera2008-05-121-1/+2
| | | | | | | | | | | | unnecessary #include lines in it. Also, move some tuple routine prototypes and macros to htup.h, which allows removal of heapam.h inclusion from some .c files. For this to work, a new header file access/sysattr.h needed to be created, initially containing attribute numbers of system columns, for pg_dump usage. While at it, make contrib ltree, intarray and hstore header files more consistent with our header style.
* Push index operator lossiness determination down to GIST/GIN opclassTom Lane2008-04-141-11/+22
| | | | | | | | | | | "consistent" functions, and remove pg_amop.opreqcheck, as per recent discussion. The main immediate benefit of this is that we no longer need 8.3's ugly hack of requiring @@@ rather than @@ to test weight-using tsquery searches on GIN indexes. In future it should be possible to optimize some other queries better than is done now, by detecting at runtime whether the index match is exact or not. Tom Lane, after an idea of Heikki's, and with some help from Teodor.
* Phase 2 of project to make index operator lossiness be determined at runtimeTom Lane2008-04-131-20/+22
| | | | | | | | | | | | instead of plan time. Extend the amgettuple API so that the index AM returns a boolean indicating whether the indexquals need to be rechecked, and make that rechecking happen in nodeIndexscan.c (currently the only place where it's expected to be needed; other callers of index_getnext are just erroring out for now). For the moment, GIN and GIST have stub logic that just always sets the recheck flag to TRUE --- I'm hoping to get Teodor to handle pushing that control down to the opclass consistent() functions. The planner no longer pays any attention to amopreqcheck, and that catalog column will go away in due course.
* Replace "amgetmulti" AM functions with "amgetbitmap", in which the wholeTom Lane2008-04-101-23/+32
| | | | | | | | | | | | | | | | | | indexscan always occurs in one call, and the results are returned in a TIDBitmap instead of a limited-size array of TIDs. This should improve speed a little by reducing AM entry/exit overhead, and it is necessary infrastructure if we are ever to support bitmap indexes. In an only slightly related change, add support for TIDBitmaps to preserve (somewhat lossily) the knowledge that particular TIDs reported by an index need to have their quals rechecked when the heap is visited. This facility is not really used yet; we'll need to extend the forced-recheck feature to plain indexscans before it's useful, and that hasn't been coded yet. The intent is to use it to clean up 8.3's horrid @@@ kluge for text search with weighted queries. There might be other uses in future, but that one alone is sufficient reason. Heikki Linnakangas, with some adjustments by me.
* Update copyrights in source tree to 2008.Bruce Momjian2008-01-011-2/+2
|
* pgindent run for 8.3.Bruce Momjian2007-11-151-10/+11
|
* Redefine the lp_flags field of item pointers as having four states, ratherTom Lane2007-09-121-4/+4
| | | | | | | | | than two independent bits (one of which was never used in heap pages anyway, or at least hadn't been in a very long time). This gives us flexibility to add the HOT notions of redirected and dead item pointers without requiring anything so klugy as magic values of lp_off and lp_len. The state values are chosen so that for the states currently in use (pre-HOT) there is no change in the physical representation.
* Fix up pgstats counting of live and dead tuples to recognize that committedTom Lane2007-05-271-2/+2
| | | | | | | | | | | and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
* Make 'col IS NULL' clauses be indexable conditions.Tom Lane2007-04-061-25/+33
| | | | Teodor Sigaev, with some kibitzing from Tom Lane.
* Refactor the index AM API slightly: move currentItemData andNeil Conway2007-01-201-8/+9
| | | | | | | currentMarkData from IndexScanDesc to the opaque structs for the AMs that need this information (currently gist and hash). Patch from Heikki Linnakangas, fixes by Neil Conway.
* Update CVS HEAD for 2007 copyright. Back branches are typically notBruce Momjian2007-01-051-2/+2
| | | | back-stamped for this.
* Fix some typos in comments.Neil Conway2006-11-121-2/+2
|
* pgindent run for 8.2.Bruce Momjian2006-10-041-8/+11
|
* Remove 576 references of include files that were not needed.Bruce Momjian2006-07-141-2/+1
|
* Alphabetically order reference to include files, "G" - "M".Bruce Momjian2006-07-111-2/+2
|
* ChangesTeodor Sigaev2006-06-281-2/+1
| | | | | | | | | | | | | | | | | | | | * new split algorithm (as proposed in http://archives.postgresql.org/pgsql-hackers/2006-06/msg00254.php) * possible call pickSplit() for second and below columns * add spl_(l|r)datum_exists to GIST_SPLITVEC - pickSplit should check its values to use already defined spl_(l|r)datum for splitting. pickSplit should set spl_(l|r)datum_exists to 'false' (if they was 'true') to signal to caller about using spl_(l|r)datum. * support for old pickSplit(): not very optimal but correct split * remove 'bytes' field from GISTENTRY: in any case size of value is defined by it's type. * split GIST_SPLITVEC to two structures: one for using in picksplit and second - for internal use. * some code refactoring * support of subsplit to rtree opclasses TODO: add support of subsplit to contrib modules
* * Add support NULL to GiST.Teodor Sigaev2006-05-241-9/+10
| | | | | | | | * some refactoring and simplify code int gistutil.c and gist.c * now in some cases it can be called used-defined picksplit method for non-first column in index, but here is a place to do more. * small fix of docs related to support NULL.
* Update copyright for 2006. Update scripts.Bruce Momjian2006-03-051-2/+2
|
* Some minor code cleanup, falling out from the removal of rtree. SK_NEGATETom Lane2006-01-141-8/+10
| | | | | | | | | | | | isn't being used anywhere anymore, and there seems no point in a generic index_keytest() routine when two out of three remaining access methods aren't using it. Also, add a comment documenting a convention for letting access methods define private flag bits in ScanKey sk_flags. There are no such flags at the moment but I'm thinking about changing btree's handling of "required keys" to use flag bits in the keys rather than a count of required key positions. Also, if some AM did still want SK_NEGATE then it would be reasonable to treat it as a private flag bit.
* Re-run pgindent, fixing a problem where comment lines after a blankBruce Momjian2005-11-221-3/+3
| | | | | | | | | comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
* Add simple sanity checks on newly-read pages to GiST, too.Tom Lane2005-11-061-3/+7
|
* Revise pgstats stuff to fix the problems with not counting accessesTom Lane2005-10-061-1/+5
| | | | | | | generated by bitmap index scans. Along the way, simplify and speed up the code for counting sequential and index scans; it was both confusing and inefficient to be taking care of that in the per-tuple loops, IMHO. initdb forced because of internal changes in pg_stat view definitions.
* pgindent new GIST index code, per request from Tom.Bruce Momjian2005-09-221-117/+133
|
* Concurrency for GiSTTeodor Sigaev2005-06-271-122/+204
| | | | | | | | | | | | | | | | | | - full concurrency for insert/update/select/vacuum: - select and vacuum never locks more than one page simultaneously - select (gettuple) hasn't any lock across it's calls - insert never locks more than two page simultaneously: - during search of leaf to insert it locks only one page simultaneously - while walk upward to the root it locked only parent (may be non-direct parent) and child. One of them X-lock, another may be S- or X-lock - 'vacuum full' locks index - improve gistgetmulti - simplify XLOG records Fix bug in index_beginscan_internal: LockRelation may clean rd_aminfo structure, so move GET_REL_PROCEDURE after LockRelation
* 1. full functional WAL for GiSTTeodor Sigaev2005-06-201-8/+8
| | | | | | | | | | | 2. improve vacuum for gist - use FSM - full vacuum: - reforms parent tuple if it's needed ( tuples was deleted on child page or parent tuple remains invalid after crash recovery ) - truncate index file if possible 3. fixes bugs and mistakes
View Lorry Controller Status