aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* Arrange to convert EXISTS subqueries that are equivalent to hashable INTom Lane2008-08-22
| | | | | | | | | | | | | | | | | | | | | | | subqueries into the same thing you'd have gotten from IN (except always with unknownEqFalse = true, so as to get the proper semantics for an EXISTS). I believe this fixes the last case within CVS HEAD in which an EXISTS could give worse performance than an equivalent IN subquery. The tricky part of this is that if the upper query probes the EXISTS for only a few rows, the hashing implementation can actually be worse than the default, and therefore we need to make a cost-based decision about which way to use. But at the time when the planner generates plans for subqueries, it doesn't really know how many times the subquery will be executed. The least invasive solution seems to be to generate both plans and postpone the choice until execution. Therefore, in a query that has been optimized this way, EXPLAIN will show two subplans for the EXISTS, of which only one will actually get executed. There is a lot more that could be done based on this infrastructure: in particular it's interesting to consider switching to the hash plan if we start out using the non-hashed plan but find a lot more upper rows going by than we expected. I have therefore left some minor inefficiencies in place, such as initializing both subplans even though we will currently only use one.
* Mention that pg_dump does not dump ALTER DATABASE ... SET commands;Bruce Momjian2008-08-21
| | | | backpatch to 8.3.X. Also fix markup that had just one bullet.
* Update URL.Alvaro Herrera2008-08-21
|
* Autoconf 2.62 will require cache variables to contain "_cv_". Fix our fewPeter Eisentraut2008-08-21
| | | | noncomplying cases to be future-proof.
* Marginal improvement in sublink planning: allow unknownEqFalse optimizationTom Lane2008-08-20
| | | | | | | to be used for SubLinks that are underneath a top-level OR clause. Just as at the very top level of WHERE, it's not necessary to be accurate about whether the sublink returns FALSE or NULL, because either result has the same impact on whether the WHERE will succeed.
* Remove tools and documention for generating TODO.html.Bruce Momjian2008-08-20
|
* TODO now in wiki, html version removed.Bruce Momjian2008-08-20
|
* New TODO list URL wiki location listed; contents truncated.Bruce Momjian2008-08-20
|
* Fix obsolete comment. It's no longer the case that Param nodes don'tTom Lane2008-08-20
| | | | carry typmod.
* Synced parser.Michael Meskes2008-08-20
|
* Make libpq on windows not try to send chunks larger than 64Kb.Magnus Hagander2008-08-20
| | | | | | | | | Per Microsoft knowledge base article Q201213, early versions of Windows fail when we do this. Later versions of Windows appear to have a higher limit than 64Kb, but do still fail on large sends, so we unconditionally limit it for all versions. Patch from Tom Lane.
* Not done:Bruce Momjian2008-08-19
| | | | | < o -Allow an existing index to be marked as a table's primary key > o Allow an existing index to be marked as a table's primary key
* Remove -Winline from the default set of CFLAGS for gcc. It's gotten muchTom Lane2008-08-19
| | | | | too noisy to be useful as of gcc 4.3, and we were never really doing anything about inlining warnings anyway.
* Cause the output from debug_print_parse, debug_print_rewritten, andTom Lane2008-08-19
| | | | | | | | debug_print_plan to appear at LOG message level, not DEBUG1 as historically. Make debug_pretty_print default to on. Also, cause plans generated via EXPLAIN to be subject to debug_print_plan. This is all to make debug_print_plan a reasonably comfortable substitute for the former behavior of EXPLAIN VERBOSE.
* TODO done:Bruce Momjian2008-08-19
| | | | ! o Allow an existing index to be marked as a table's primary key
* Fixed incorrect argument handling in SET command if argument is a variable.Michael Meskes2008-08-19
|
* Fix some issues that prevent this file to be processed by scripts.Alvaro Herrera2008-08-19
| | | | | | | | | | While at it, mark a couple of items completed in 8.4: ! o -Prevent long-lived temporary tables from causing frozen-xid advancement starvation ! * -Improve performance of shared invalidation queue for multiple CPUs Also remove a couple of obsolete assignments.
* Add to TODO:Bruce Momjian2008-08-18
| | | | | | | | | > > * Fix all set-returning system functions so they support a wildcard > target list > > SELECT * FROM pg_get_keywords() works but SELECT * FROM > pg_show_all_settings() does not.
* Properly remove src\include\utils\probes.h when running clean.bat.Magnus Hagander2008-08-18
|
* Add some defenses against constant-FALSE outer join conditions. SinceTom Lane2008-08-17
| | | | | | | | | | | | | | | | | eval_const_expressions will generally throw away anything that's ANDed with constant FALSE, what we're left with given an example like select * from tenk1 a where (unique1,0) in (select unique2,1 from tenk1 b); is a cartesian product computation, which is really not acceptable. This is a regression in CVS HEAD compared to previous releases, which were able to notice the impossible join condition in this case --- though not in some related cases that are also improved by this patch, such as select * from tenk1 a left join tenk1 b on (a.unique1=b.unique2 and 0=1); Fix by skipping evaluation of the appropriate side of the outer join in cases where it's demonstrably unnecessary.
* Remove prohibition against SubLinks in the WHERE clause of an EXISTS subqueryTom Lane2008-08-17
| | | | | | that we're considering pulling up. I hadn't wanted to think through whether that could work during the first pass at this stuff. However, on closer inspection it seems to be safe enough.
* Improve sublink pullup code to handle ANY/EXISTS sublinks that are at topTom Lane2008-08-17
| | | | | | | | | | | | | level of a JOIN/ON clause, not only at top level of WHERE. (However, we can't do this in an outer join's ON clause, unless the ANY/EXISTS refers only to the nullable side of the outer join, so that it can effectively be pushed down into the nullable side.) Per request from Kevin Grittner. In passing, fix a bug in the initial implementation of EXISTS pullup: it would Assert if the EXIST's WHERE clause used a join alias variable. Since we haven't yet flattened join aliases when this transformation happens, it's necessary to include join relids in the computed set of RHS relids.
* Update instructions on generating TODO.html.Bruce Momjian2008-08-16
|
* probes.h is generated from probes.d, not pg_trace.d.Magnus Hagander2008-08-16
|
* Add URL for:Bruce Momjian2008-08-16
| | | | | | * Improve ability to modify views via ALTER TABLE < > http://archives.postgresql.org/pgsql-hackers/2008-08/msg00300.php
* Fix pg_dump/pg_restore's ExecuteSqlCommand() to behave suitably if PQexecTom Lane2008-08-16
| | | | | | | returns NULL instead of a PGresult. The former coding would fail, which is OK, but it neglected to give you the PQerrorMessage that might tell you why. In the oldest branches, there was another problem: it'd sometimes report PQerrorMessage from the wrong connection.
* Add to TODO:Bruce Momjian2008-08-16
| | | | | | | | | > > * Prevent query cancel packets from being replayed by an attacker, > especially when using SSL > > http://archives.postgresql.org/pgsql-hackers/2008-08/msg00345.php >
* Synchronize Borland libpq makefile to match MSVC. Backpatch to 8.3.X.Bruce Momjian2008-08-16
|
* Fix a couple of places where psql might fail to report a suitable errorTom Lane2008-08-16
| | | | | if PQexec returns NULL. These don't seem significant enough to be worth back-patching, but they ought to get fixed ...
* Update Russian FAQ.Bruce Momjian2008-08-16
| | | | corochoone@gmail.com
* Add new SQL training web site to FAQ:Bruce Momjian2008-08-16
| | | | | | <LI><A href= "http://sqlzoo.net">http://sqlzoo.net</A> </LI>
* Fix version warning bug in recently applied adjustments to psql startup.Bruce Momjian2008-08-16
| | | | Gregory Stark
* Clean up the loose ends in selectivity estimation left by my patch for semiTom Lane2008-08-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and anti joins. To do this, pass the SpecialJoinInfo struct for the current join as an additional optional argument to operator join selectivity estimation functions. This allows the estimator to tell not only what kind of join is being formed, but which variable is on which side of the join; a requirement long recognized but not dealt with till now. This also leaves the door open for future improvements in the estimators, such as accounting for the null-insertion effects of lower outer joins. I didn't do anything about that in the current patch but the information is in principle deducible from what's passed. The patch also clarifies the definition of join selectivity for semi/anti joins: it's the fraction of the left input that has (at least one) match in the right input. This allows getting rid of some very fuzzy thinking that I had committed in the original 7.4-era IN-optimization patch. There's probably room to estimate this better than the present patch does, but at least we know what to estimate. Since I had to touch CREATE OPERATOR anyway to allow a variant signature for join estimator functions, I took the opportunity to add a couple of additional checks that were missing, per my recent message to -hackers: * Check that estimator functions return float8; * Require execute permission at the time of CREATE OPERATOR on the operator's function as well as the estimator functions; * Require ownership of any pre-existing operator that's modified by the command. I also moved the lookup of the functions out of OperatorCreate() and into operatorcmds.c, since that seemed more consistent with most of the other catalog object creation processes, eg CREATE TYPE.
* Performance fix for new anti-join code in nodeMergejoin.c: after finding aTom Lane2008-08-15
| | | | | | | | | | | | | | | | | | match in antijoin mode, we should advance to next outer tuple not next inner. We know we don't want to return this outer tuple, and there is no point in advancing over matching inner tuples now, because we'd just have to do it again if the next outer tuple has the same merge key. This makes a noticeable difference if there are lots of duplicate keys in both inputs. Similarly, after finding a match in semijoin mode, arrange to advance to the next outer tuple after returning the current match; or immediately, if it fails the extra quals. The rationale is the same. (This is a performance bug in existing releases; perhaps worth back-patching? The planner tries to avoid using mergejoin with lots of duplicates, so it may not be a big issue in practice.) Nestloop and hash got this right to start with, but I made some cosmetic adjustments there to make the corresponding bits of logic look more similar.
* Make the temporary directory for pgstat files configurable by the GUCMagnus Hagander2008-08-15
| | | | | | | | variable stats_temp_directory, instead of requiring the admin to mount/symlink the pg_stat_tmp directory manually. For now the config variable is PGC_POSTMASTER. Room for further improvment that would allow it to be changed on-the-fly.
* Fix pull_up_simple_union_all to copy all rtable entries from child subquery toHeikki Linnakangas2008-08-14
| | | | | | | parent, not only those with RangeTblRefs. We need them in ExecCheckRTPerms. Report by Brendan O'Shea. Back-patch to 8.2, where pull_up_simple_union_all was introduced.
* Implement SEMI and ANTI joins in the planner and executor. (Semijoins replaceTom Lane2008-08-14
| | | | | | | | | | | | | | the old JOIN_IN code, but antijoins are new functionality.) Teach the planner to convert appropriate EXISTS and NOT EXISTS subqueries into semi and anti joins respectively. Also, LEFT JOINs with suitable upper-level IS NULL filters are recognized as being anti joins. Unify the InClauseInfo and OuterJoinInfo infrastructure into "SpecialJoinInfo". With that change, it becomes possible to associate a SpecialJoinInfo with every join attempt, which permits some cleanup of join selectivity estimation. That needs to be taken much further than this patch does, but the next step is to change the API for oprjoin selectivity functions, which seems like material for a separate patch. So for the moment the output size estimates for semi and especially anti joins are quite bogus.
* pg_buffercache needs to be taught about relation forks, as Greg StarkHeikki Linnakangas2008-08-14
| | | | pointed out.
* Add URL for:Bruce Momjian2008-08-14
| | | | | | * Improve ability to modify views via ALTER TABLE > http://archives.postgresql.org/pgsql-hackers/2008-07/msg01410.php
* Have autovacuum consider processing TOAST tables separately from theirAlvaro Herrera2008-08-13
| | | | | | | | main tables. This requires vacuum() to accept processing a toast table standalone, so there's a user-visible change in that it's now possible (for a superuser) to execute "VACUUM pg_toast.pg_toast_XXX".
* Remove TODO itemPeter Eisentraut2008-08-12
| | | | | | Allow XML to accept more liberal DOCTYPE specifications Everything works correctly, per today's email to -general.
* Add:Bruce Momjian2008-08-12
| | | | | | > * Add 'hostgss' pg_hba.conf option to allow GSS link-level encryption > > http://archives.postgresql.org/pgsql-hackers/2008-07/msg01454.php
* Relation forks patch requires a catversion bump due to changes in the formatHeikki Linnakangas2008-08-11
| | | | of some WAL records, and two-phase state files, which I forgot.
* Introduce the concept of relation forks. An smgr relation can now consistHeikki Linnakangas2008-08-11
| | | | | | | | | | | | | | | | of multiple forks, and each fork can be created and grown separately. The bulk of this patch is about changing the smgr API to include an extra ForkNumber argument in every smgr function. Also, smgrscheduleunlink and smgrdounlink no longer implicitly call smgrclose, because other forks might still exist after unlinking one. The callers of those functions have been modified to call smgrclose instead. This patch in itself doesn't have any user-visible effect, but provides the infrastructure needed for upcoming patches. The additional forks envisioned are a rewritten FSM implementation that doesn't rely on a fixed-size shared memory block, and a visibility map to allow skipping portions of a table in VACUUM that have no dead tuples.
* Fix corner-case bug introduced with HOT: if REINDEX TABLE pg_class (or aTom Lane2008-08-10
| | | | | | | | | | | | REINDEX DATABASE including same) is done before a session has done any other update on pg_class, the pg_class relcache entry was left with an incorrect setting of rd_indexattr, because the indexed-attributes set would be first demanded at a time when we'd forced a partial list of indexes into the pg_class entry, and it would remain cached after that. This could result in incorrect decisions about HOT-update safety later in the same session. In practice, since only pg_class_relname_nsp_index would be missed out, only ALTER TABLE RENAME and ALTER TABLE SET SCHEMA could trigger a problem. Per report and test case from Ondrej Jirman.
* Install checks in executor startup to ensure that the tuples produced by anTom Lane2008-08-08
| | | | | | | | | | | | INSERT or UPDATE will match the target table's current rowtype. In pre-8.3 releases inconsistency can arise with stale cached plans, as reported by Merlin Moncure. (We patched the equivalent hazard on the SELECT side in Feb 2007; I'm not sure why we thought there was no risk on the insertion side.) In 8.3 and HEAD this problem should be impossible due to plan cache invalidation management, but it seems prudent to make the check anyway. Back-patch as far as 8.0. 7.x versions lack ALTER COLUMN TYPE, so there seems no way to abuse a stale plan comparably.
* Improve INTERSECT/EXCEPT hashing by realizing that we don't need to make anyTom Lane2008-08-07
| | | | | | | | | hashtable entries for tuples that are found only in the second input: they can never contribute to the output. Furthermore, this implies that the planner should endeavor to put first the smaller (in number of groups) input relation for an INTERSECT. Implement that, and upgrade prepunion's estimation of the number of rows returned by setops so that there's some amount of sanity in the estimate of which one is smaller.
* Support hashing for duplicate-elimination in INTERSECT and EXCEPT queries.Tom Lane2008-08-07
| | | | | | | | | | This completes my project of improving usage of hashing for duplicate elimination (aggregate functions with DISTINCT remain undone, but that's for some other day). As with the previous patches, this means we can INTERSECT/EXCEPT on datatypes that can hash but not sort, and it means that INTERSECT/EXCEPT without ORDER BY are no longer certain to produce sorted output.
* Teach the system how to use hashing for UNION. (INTERSECT/EXCEPT will follow,Tom Lane2008-08-07
| | | | | | | | | | | but seem like a separate patch since most of the remaining work is on the executor side.) I took the opportunity to push selection of the grouping operators for set operations into the parser where it belongs. Otherwise this is just a small exercise in making prepunion.c consider both alternatives. As with the recent DISTINCT patch, this means we can UNION on datatypes that can hash but not sort, and it means that UNION without ORDER BY is no longer certain to produce sorted output.
* Do not allow Unique nodes to be scanned backwards. The code claimed that itTom Lane2008-08-05
| | | | | | | would work, but in fact it didn't return the same rows when moving backwards as when moving forwards. This would have no visible effect in a DISTINCT query (at least assuming the column datatypes use a strong definition of equality), but it gave entirely wrong answers for DISTINCT ON queries.
generated by cgit v1.2.3 (git 2.25.1) at 2025-05-31 05:41:39 +0000