aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* Fix bogus EXPLAIN display of rowcount estimates for BitmapAnd andTom Lane2005-04-23
| | | | BitmapOr nodes.
* First cut at planner support for bitmap index scans. Lots to do yet,Tom Lane2005-04-22
| | | | | | | | but the code is basically working. Along the way, rewrite the entire approach to processing OR index conditions, and make it work in join cases for the first time ever. orindxpath.c is now basically obsolete, but I left it in for the time being to allow easy comparison testing against the old implementation.
* Rethink original decision to use AND/OR Expr nodes to represent bitmapTom Lane2005-04-21
| | | | | | | logic operations during planning. Seems cleaner to create two new Path node types, instead --- this avoids duplication of cost-estimation code. Also, create an enable_bitmapscan GUC parameter to control use of bitmap plans.
* Install some slightly realistic cost estimation for bitmap index scans.Tom Lane2005-04-21
|
* Make pg_ctl status do a kill() test to verify that the PID found inTom Lane2005-04-20
| | | | postmaster.pid still represents a live postmaster.
* Don't try to run clauseless index scans on index types that don't supportTom Lane2005-04-20
| | | | it. Per report from Marinos Yannikos.
* Fix mis-display of negative fractional seconds in interval values forTom Lane2005-04-20
| | | | --enable-integer-datetimes case. Per report from Oliver Siegmar.
* Minor performance improvement: avoid unnecessary creation/unioning ofTom Lane2005-04-20
| | | | | bitmaps for multiple indexscans. Instead just let each indexscan add TIDs directly into the BitmapOr node's result bitmap.
* Create executor and planner-backend support for decoupled heap and indexTom Lane2005-04-19
| | | | | | | | | scans, using in-memory tuple ID bitmaps as the intermediary. The planner frontend (path creation and cost estimation) is not there yet, so none of this code can be executed. I have tested it using some hacked planner code that is far too ugly to see the light of day, however. Committing now so that the bulk of the infrastructure changes go in before the tree drifts under me.
* Attached patch gets rid of the global timezone in the following steps:Bruce Momjian2005-04-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | * Changes the APIs to the timezone functions to take a pg_tz pointer as an argument, representing the timezone to use for the selected operation. * Adds a global_timezone variable that represents the current timezone in the backend as set by SET TIMEZONE (or guc, or env, etc). * Implements a hash-table cache of loaded tables, so we don't have to read and parse the TZ file everytime we change a timezone. While not necesasry now (we don't change timezones very often), I beleive this will be necessary (or at least good) when "multiple timezones in the same query" is eventually implemented. And code-wise, this was the time to do it. There are no user-visible changes at this time. Implementing the "multiple zones in one query" is a later step... This also gets rid of some of the cruft needed to "back out a timezone change", since we previously couldn't check a timezone unless it was activated first. Passes regression tests on win32, linux (slackware 10) and solaris x86. Magnus Hagander
* pg_dumpall should enforce the server version check for itself, ratherTom Lane2005-04-18
| | | | | than simply passing it down to pg_dump. Else, version-related failures in pg_dumpall itself generate unhelpful error messages.
* record_in and record_recv must be careful to return a separatelyTom Lane2005-04-18
| | | | | pfree'able result, since some callers expect to be able to pfree the result of a pass-by-reference function. Per report from Chris Trawick.
* Initial implementation of lossy-tuple-bitmap data structures.Tom Lane2005-04-17
| | | | Not connected to anything useful yet ...
* Fix comment typo.Bruce Momjian2005-04-17
|
* Create a new 'MultiExecProcNode' call API for plan nodes that don'tTom Lane2005-04-16
| | | | | | | return just a single tuple at a time. Currently the only such node type is Hash, but I expect we will soon have indexscans that can return tuple bitmaps. A side benefit is that EXPLAIN ANALYZE now shows the correct tuple count for a Hash node.
* Reduce PANIC to ERROR in several xlog routines that are used in bothTom Lane2005-04-15
| | | | | | | | | | critical and noncritical contexts (an example of noncritical being post-checkpoint removal of dead xlog segments). In the critical cases the CRIT_SECTION mechanism will cause ERROR to be promoted to PANIC anyway, and in the noncritical cases we shouldn't let an error take down the entire database. Arguably there should be *no* explicit PANIC errors in this module, only more START/END_CRIT_SECTION calls, but I didn't go that far. (Yet.)
* Modify MoveOfflineLogs/InstallXLogFileSegment to avoid O(N^2) behaviorTom Lane2005-04-15
| | | | | | | when recycling a large number of xlog segments during checkpoint. The former behavior searched from the same start point each time, requiring O(checkpoint_segments^2) stat() calls to relocate all the segments. Instead keep track of where we stopped last time through.
* Revert addition of poorly-thought-out DUMP TIMESTAMP archive entry,Tom Lane2005-04-15
| | | | | | | | which induced bug #1597 in addition to having several other misbehaviors (like labeling the dump with a completion time having nothing to do with reality). Instead just print out the desired strings where RestoreArchive was already emitting the 'PostgreSQL database dump' and 'PostgreSQL database dump complete' strings.
* This patch changes the use of varargs.h to stdarg.h asNeil Conway2005-04-15
| | | | | | required by modern versions of GCC. Niels Breet
* Remove an unused variable "waitingForSignal". From Qingqing Zhou.Neil Conway2005-04-15
|
* Make equalTupleDescs() compare attlen/attbyval/attalign rather thanTom Lane2005-04-14
| | | | | | | | | | assuming comparison of atttypid is sufficient. In a dropped column atttypid will be 0, and we'd better check the physical-storage data to make sure the tupdescs are physically compatible. I do not believe there is a real risk before 8.0, since before that we only used this routine to compare successive states of the tupdesc for a particular relation. But 8.0's typcache.c might be comparing arbitrary tupdescs so we'd better play it safer.
* Put back blessing of record-function tupledesc, which I removed in aTom Lane2005-04-14
| | | | fit of over-optimization.
* Don't try to constant-fold functions returning RECORD, since the optimizerTom Lane2005-04-14
| | | | | isn't presently set up to pass them an expected tuple descriptor. Bug has been there since 7.3 but was just recently reported by Thomas Hallgren.
* Must count '*' characters as potential arguments.Tom Lane2005-04-14
|
* Marginal hack to use a specialized hash function for dynahash hashtablesTom Lane2005-04-14
| | | | | | whose keys are OIDs. The only one that looks particularly performance critical is the relcache hashtable, but as long as we've got the function we may as well use it wherever it's applicable.
* Completion of project to use fixed OIDs for all system catalogs andTom Lane2005-04-14
| | | | | | | indexes. Replace all heap_openr and index_openr calls by heap_open and index_open. Remove runtime lookups of catalog OID numbers in various places. Remove relcache's support for looking up system catalogs by name. Bulky but mostly very boring patch ...
* Added patch by Philip Yarra <philip.yarra@internode.on.net> for a bug in ↵Michael Meskes2005-04-14
| | | | thread support.
* First phase of project to use fixed OIDs for all system catalogs andTom Lane2005-04-14
| | | | | | | | | | | | | | | | indexes. Extend the macros in include/catalog/*.h to carry the info about hand-assigned OIDs, and adjust the genbki script and bootstrap code to make the relations actually get those OIDs. Remove the small number of RelOid_pg_foo macros that we had in favor of a complete set named like the catname.h and indexing.h macros. Next phase will get rid of internal use of names for looking up catalogs and indexes; but this completes the changes forcing an initdb, so it looks like a good place to commit. Along the way, I made the shared relations (pg_database etc) not be 'bootstrap' relations any more, so as to reduce the number of hardwired entries and simplify changing those relations in future. I'm not sure whether they ever really needed to be handled as bootstrap relations, but it seems to work fine to not do so now.
* Simplify initdb-time assignment of OIDs as I proposed yesterday, andTom Lane2005-04-13
| | | | | | | | avoid encroaching on the 'user' range of OIDs by allowing automatic OID assignment to use values below 16k until we reach normal operation. initdb not forced since this doesn't make any incompatible change; however a lot of stuff will have different OIDs after your next initdb.
* Change addRangeTableEntryForRelation() to take a Relation pointer insteadTom Lane2005-04-13
| | | | | | | | | | of just a relation OID, thereby not having to open the relation for itself. This actually saves code rather than adding it for most of the existing callers, which had the rel open already. The main point though is to be able to use this rather than plain addRangeTableEntry in setTargetTable, thus saving one relation_openrv/relation_close cycle for every INSERT, UPDATE, or DELETE. Seems to provide a several percent win on simple INSERTs.
* Revert yesterday's change to make pg_cast.h say 'OID = 0' in DATA entries.Tom Lane2005-04-13
| | | | On reflection, we ought to get rid of that mechanism entirely.
* Adjust pg_cast.h so that the OIDs assigned to built-in casts come fromTom Lane2005-04-12
| | | | | | | | | genbki.sh's pool (10000-16383) instead of being run-time assigned by heap_insert. Might as well use the pool as long as it's there ... I was a bit bemused to realize that it hadn't been in use at all since 7.2. initdb not forced since this doesn't really affect anything. The OIDs of casts and system indexes will change next time you do one, though.
* Remove unnecessary UPDATE commands to assign explicit ACLs to functionsTom Lane2005-04-12
| | | | | | | | | and PL languages during initdb. The default permissions for these objects are the same as what we were assigning anyway, so there is no need to expend space in the catalogs on them. The space cost is particularly significant in pg_proc's indexes, which are bloated by about a factor of 2 by the full-table update, and can never really recover the space. initdb not forced, since the change has no actual impact on behavior.
* Revert mistaken renaming of UTF-8.Peter Eisentraut2005-04-12
|
* Fix oversight in MIN/MAX optimization: must not return NULL entriesTom Lane2005-04-12
| | | | from index, since the aggregates ignore NULLs.
* Add aggsortop column to pg_aggregate, so that MIN/MAX optimization canTom Lane2005-04-12
| | | | | | | | be supported for all datatypes. Add CREATE AGGREGATE and pg_dump support too. Add specialized min/max aggregates for bpchar, instead of depending on text's min/max, because otherwise the possible use of bpchar indexes cannot be recognized. initdb forced because of catalog changes.
* Create the planner mechanism for optimizing simple MIN and MAX queriesTom Lane2005-04-11
| | | | | | into indexscans on matching indexes. For the moment, it only handles int4 and text datatypes; next step is to add a column to pg_aggregate so that all MIN/MAX aggregates can be handled. Per my recent proposal.
* Fix interaction between materializing holdable cursors and firingTom Lane2005-04-11
| | | | | | deferred triggers: either one can create more work for the other, so we have to loop till it's all gone. Per example from andrew@supernews. Add a regression test to help spot trouble in this area in future.
* PersistHoldablePortal must establish the correct value for ActiveSnapshotTom Lane2005-04-11
| | | | | | while completing execution of the cursor's query. Otherwise we get wrong answers or even crashes from non-volatile functions called by the query. Per report from andrew@supernews.
* Make constant-folding produce sane output for COALESCE(NULL,NULL),Tom Lane2005-04-10
| | | | | that is a plain NULL and not a COALESCE with no inputs. Fixes crash reported by Michael Williamson.
* Split out into a separate function the code in grouping_planner() thatTom Lane2005-04-10
| | | | | | | decides whether to use hashed grouping instead of sort-plus-uniq grouping. The function needs an annoyingly large number of parameters, but this still seems like a win for legibility, since it removes over a hundred lines from grouping_planner (which is still too big :-().
* SQL functions returning pass-by-reference types were copying the resultsTom Lane2005-04-10
| | | | | into the wrong memory context, resulting in a query-lifespan memory leak. Bug is new in 8.0, I believe. Per report from Rae Stiening.
* If we're going to have a non-panic check for held_lwlocks[] overrun,Tom Lane2005-04-08
| | | | | it must occur *before* we get into the critical state of holding a lock we have no place to record. Per discussion with Qingqing Zhou.
* Use an always-there test, not an Assert, to check for overrun ofTom Lane2005-04-08
| | | | the held_lwlocks[] array. Per Qingqing Zhou.
* Change the default setting of "add_missing_from" to false. This has beenNeil Conway2005-04-08
| | | | | | the long-term plan for this behavior for quite some time, but it is only possible now that DELETE has a USING clause so that the user can join other tables in a DELETE statement without relying on this behavior.
* Use fork_process() to avoid some fork()-related boilerplate code whenNeil Conway2005-04-08
| | | | forking the stats collector child process.
* Fix some issues with missing or too many newlines atTom Lane2005-04-07
| | | | end of file.
* Allow plpgsql functions to omit RETURN command when the function returnsTom Lane2005-04-07
| | | | | | output parameters or VOID or a set. There seems no particular reason to insist on a RETURN in these cases, since the function return value is determined by other elements anyway. Per recent discussion.
* Fix minor breakage to regression tests induced in previous commit -- I hadNeil Conway2005-04-07
| | | | updated the expected/ output, not the output/ output. Apologies.
* Add a "USING" clause to DELETE, which is equivalent to the FROM clauseNeil Conway2005-04-07
| | | | | | | | | | | | | | | in UPDATE. We also now issue a NOTICE if a query has _any_ implicit range table entries -- in the past, we would only warn about implicit RTEs in SELECTs with at least one explicit RTE. As a result of the warning change, 25 of the regression tests had to be updated. I also took the opportunity to remove some bogus whitespace differences between some of the float4 and float8 variants. I believe I have correctly updated all the platform-specific variants, but let me know if that's not the case. Original patch for DELETE ... USING from Euler Taveira de Oliveira, reworked by Neil Conway.