- 22 Sep, 2007 1 commit
-
-
Tom Lane authored
(because they are uncorrelated with the immediate parent query). We were charging the full run cost to the parent node, disregarding the fact that only one row need be fetched for EXISTS. While this would only be a cosmetic issue in most cases, it might possibly affect planning outcomes if the parent query were itself a subquery to some upper query. Per recent discussion with Steve Crawford.
-
- 26 Aug, 2007 1 commit
-
-
Tom Lane authored
sub-select returns zero rows. Per complaint from Jens Schicke. Since this is more in the nature of a definition change than a bug, not back-patched.
-
- 18 Jul, 2007 1 commit
-
-
Tom Lane authored
a MIN or MAX aggregate call into an indexscan: the initplan is being made at the current query nesting level and so we shouldn't increment query_level. Though usually harmless, this mistake could lead to bogus "plan should not reference subplan's variable" failures on complex queries. Per bug report from David Sanchez i Gregori.
-
- 27 Feb, 2007 1 commit
-
-
Tom Lane authored
parent query's EState. Now that there's a single flat rangetable for both the main plan and subplans, there's no need anymore for a separate EState, and removing it allows cleaning up some crufty code in nodeSubplan.c and nodeSubqueryscan.c. Should be a tad faster too, although any difference will probably be hard to measure. This is the last bit of subsidiary mop-up work from changing to a flat rangetable.
-
- 22 Feb, 2007 1 commit
-
-
Tom Lane authored
useless substructure for its RangeTblEntry nodes. (I chose to keep using the same struct node type and just zero out the link fields for unneeded info, rather than making a separate ExecRangeTblEntry type --- it seemed too fragile to have two different rangetable representations.) Along the way, put subplans into a list in the toplevel PlannedStmt node, and have SubPlan nodes refer to them by list index instead of direct pointers. Vadim wanted to do that years ago, but I never understood what he was on about until now. It makes things a *whole* lot more robust, because we can stop worrying about duplicate processing of subplans during expression tree traversals. That's been a constant source of bugs, and it's finally gone. There are some consequent simplifications yet to be made, like not using a separate EState for subplans in the executor, but I'll tackle that later.
-
- 19 Feb, 2007 2 commits
-
-
Tom Lane authored
this code was last gone over, there wasn't really any alternative to globals because we didn't have the PlannerInfo struct being passed all through the planner code. Now that we do, we can restructure things to avoid non-reentrancy. I'm fooling with this because otherwise I'd have had to add another global variable for the planned compact range table list.
-
Tom Lane authored
plan nodes, so that the executor does not need to get these items from the range table at runtime. This will avoid needing to include these fields in the compact range table I'm expecting to make the executor use.
-
- 06 Feb, 2007 1 commit
-
-
Tom Lane authored
that aren't turned into true joins). Since this is the last missing bit of infrastructure, go ahead and fill out the hash integer_ops and float_ops opfamilies with cross-type operators. The operator family project is now DONE ... er, except for documentation ...
-
- 10 Jan, 2007 1 commit
-
-
Tom Lane authored
which comparison operators to use for plan nodes involving tuple comparison (Agg, Group, Unique, SetOp). Formerly the executor looked up the default equality operator for the datatype, which was really pretty shaky, since it's possible that the data being fed to the node is sorted according to some nondefault operator class that could have an incompatible idea of equality. The planner knows what it has sorted by and therefore can provide the right equality operator to use. Also, this change moves a couple of catalog lookups out of the executor and into the planner, which should help startup time for pre-planned queries by some small amount. Modify the planner to remove some other cavalier assumptions about always being able to use the default operators. Also add "nulls first/last" info to the Plan node for a mergejoin --- neither the executor nor the planner can cope yet, but at least the API is in place.
-
- 05 Jan, 2007 1 commit
-
-
Bruce Momjian authored
back-stamped for this.
-
- 23 Dec, 2006 1 commit
-
-
Tom Lane authored
cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
-
- 10 Dec, 2006 1 commit
-
-
Tom Lane authored
representing externally-supplied values, since the APIs that carry such values only specify type not typmod. However, for PARAM_SUBLINK Params it is handy to carry the typmod of the sublink's output column. This is a much cleaner solution for the recently reported 'could not find pathkey item to sort' and 'failed to find unique expression in subplan tlist' bugs than my original 8.2-compatible patch. Besides, someday we might want to support typmods for external parameters ...
-
- 06 Dec, 2006 1 commit
-
-
Tom Lane authored
a sublink's test expression have the correct vartypmod, rather than defaulting to -1. There's at least one place where this is important because we're expecting these Vars to be exactly equal() to those appearing in the subplan itself. This is a pretty klugy solution --- it would likely be cleaner to change Param nodes to include a typmod field --- but we can't do that in the already-released 8.2 branch. Per bug report from Hubert Fongarnand.
-
- 04 Oct, 2006 1 commit
-
-
Bruce Momjian authored
-
- 02 Aug, 2006 1 commit
-
-
Joe Conway authored
(e.g. "INSERT ... VALUES (...), (...), ...") and elsewhere as allowed by the spec. (e.g. similar to a FROM clause subselect). initdb required. Joe Conway and Tom Lane.
-
- 14 Jul, 2006 1 commit
-
-
Bruce Momjian authored
-
- 11 Jul, 2006 1 commit
-
-
Bruce Momjian authored
-
- 28 Jun, 2006 1 commit
-
-
Tom Lane authored
-
- 03 May, 2006 1 commit
-
-
Tom Lane authored
initPlan sets a parameter for another. This could not (I think) happen before 8.1, but it's possible now because the initPlans generated by MIN/MAX optimization might themselves use initPlans. We attach those initPlans as siblings of the MIN/MAX ones, not children, to avoid duplicate computation when multiple MIN/MAX aggregates are present; so this leads to the case of an initPlan needing the result of a sibling initPlan, which is not possible with ordinary query nesting. Hadn't been noticed because in most contexts having too much stuff listed in extParam is fairly harmless. Fixes "plan should not reference subplan's variable" bug reported by Catalin Pitis.
-
- 28 Apr, 2006 1 commit
-
-
Tom Lane authored
MIN/MAX not be converted to use an index if the query WHERE clause contains any volatile functions or subplans. I had originally feared that the conversion might alter the behavior of such a query with respect to a volatile function. Well, so it might, but only in the sense that the function would get evaluated at a subset of the table rows rather than all of them --- and we have never made any such guarantee anyway. (For instance, we don't refuse to use an index for an ordinary non-aggregate query when one of the non-indexable filter conditions contains a volatile function.) The prohibition against subplans was because of worry that that case wasn't adequately tested, which it wasn't, but it turns out to be possible to make 8.1 fail anyway: regression=# select o.ten, (select max(unique2) from tenk1 i where ten = o.ten or ten = (select f1 from int4_tbl limit 1)) from tenk1 o; ERROR: direct correlated subquery unsupported as initplan This is due to bogus code in SS_make_initplan_from_plan (it's an initplan, ergo it can't have any parParams). Having fixed that, we might as well allow subplans as well as initplans.
-
- 22 Apr, 2006 1 commit
-
-
Tom Lane authored
not named ones, and replace linear searches of the list with array indexing. The named-parameter support has been dead code for many years anyway, and recent profiling suggests that the searching was costing a noticeable amount of performance for complex queries.
-
- 05 Mar, 2006 1 commit
-
-
Bruce Momjian authored
-
- 28 Dec, 2005 1 commit
-
-
Tom Lane authored
(previously we only did = and <> correctly). Also, allow row comparisons with any operators that are in btree opclasses, not only those with these specific names. This gets rid of a whole lot of indefensible assumptions about the behavior of particular operators based on their names ... though it's still true that IN and NOT IN expand to "= ANY". The patch adds a RowCompareExpr expression node type, and makes some changes in the representation of ANY/ALL/ROWCOMPARE SubLinks so that they can share code with RowCompareExpr. I have not yet done anything about making RowCompareExpr an indexable operator, but will look at that soon. initdb forced due to changes in stored rules.
-
- 26 Nov, 2005 1 commit
-
-
Tom Lane authored
"ctid IN (list)" will still work after we convert IN to ScalarArrayOpExpr. Make some minor efficiency improvements while at it, such as ensuring that multiple TIDs are fetched in physical heap order. And fix EXPLAIN so that it shows what's really going on for a TID scan.
-
- 22 Nov, 2005 1 commit
-
-
Bruce Momjian authored
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.
-
- 15 Oct, 2005 1 commit
-
-
Bruce Momjian authored
-
- 05 Jun, 2005 1 commit
-
-
Tom Lane authored
a new PlannerInfo struct, which is passed around instead of the bare Query in all the planning code. This commit is essentially just a code-beautification exercise, but it does open the door to making larger changes to the planner data structures without having to muck with the widely-known Query struct.
-
- 25 Apr, 2005 1 commit
-
-
Tom Lane authored
node, as this behavior is now better done as a bitmap OR indexscan. This allows considerable simplification in nodeIndexscan.c itself as well as several planner modules concerned with indexscan plan generation. Also we can improve the sharing of code between regular and bitmap indexscans, since they are now working with nigh-identical Plan nodes.
-
- 19 Apr, 2005 1 commit
-
-
Tom Lane authored
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.
-
- 11 Apr, 2005 1 commit
-
-
Tom Lane authored
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.
-
- 06 Apr, 2005 1 commit
-
-
Tom Lane authored
few palloc's. I also chose to eliminate the restype and restypmod fields entirely, since they are redundant with information stored in the node's contained expression; re-examining the expression at need seems simpler and more reliable than trying to keep restype/restypmod up to date. initdb forced due to change in contents of stored rules.
-
- 31 Dec, 2004 1 commit
-
-
PostgreSQL Daemon authored
Tag appropriate files for rc3 Also performed an initial run through of upgrading our Copyright date to extend to 2005 ... first run here was very simple ... change everything where: grep 1996-2004 && the word 'Copyright' ... scanned through the generated list with 'less' first, and after, to make sure that I only picked up the right entries ...
-
- 29 Aug, 2004 2 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
-
- 30 May, 2004 1 commit
-
-
Neil Conway authored
list compatibility API by default. While doing this, I decided to keep the llast() macro around and introduce llast_int() and llast_oid() variants.
-
- 26 May, 2004 1 commit
-
-
Neil Conway authored
In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
-
- 11 May, 2004 1 commit
-
-
Tom Lane authored
-
- 03 Feb, 2004 1 commit
-
-
Tom Lane authored
Make btree index creation and initial validation of foreign-key constraints use maintenance_work_mem rather than work_mem as their memory limit. Add some code to guc.c to allow these variables to be referenced by their old names in SHOW and SET commands, for backwards compatibility.
-
- 12 Jan, 2004 1 commit
-
-
Tom Lane authored
already-canonicalized qual expression.
-
- 29 Nov, 2003 1 commit
-
-
PostgreSQL Daemon authored
$Header: -> $PostgreSQL Changes ...
-