| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
| |
and
for src/data directories, and one minor patch for doc/README.locale.
Please apply.
Oleg.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
store all ordering information in pathkeys lists (which are now lists of
lists of PathKeyItem nodes, not just lists of lists of vars). This was
a big win --- the code is smaller and IMHO more understandable than it
was, even though it handles more cases. I believe the node changes will
not force an initdb for anyone; planner nodes don't show up in stored
rules.
|
| |
|
| |
|
|
|
|
| |
since it's now needed in both optimizer and parser.
|
|
|
|
| |
Patches created by Hiroki Kataoka.
|
|
|
|
|
| |
Also, improve it so that it checks for multi-column constraints.
Thanks to Mark Dalphin <mdalphin@amgen.com> for reporting the problem.
|
| |
|
|
|
|
|
| |
l2 contained more than one entry, there would be duplicates in the output
list. Miscellaneous code beautification in other routines, too.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
commuted (ie, the index var appears on the right). These are now handled
the same way as merge and hash join quals that need to be commuted: the
actual reversing of the clause only happens if we actually choose the path
and generate a plan from it. Furthermore, the clause is only reversed in
the 'indexqual' field of the plan, not in the 'indxqualorig' field. This
allows the clause to still be recognized and removed from qpquals of upper
level join plans. Also, simplify and generalize match_clause_to_indexkey;
now it recognizes binary-compatible indexes for join as well as restriction
clauses.
|
|
|
|
|
|
|
| |
contains much code that looks like it will handle indexquals with the index
key on either side of the operator, in fact indexquals must have the index
key on the left because of limitations of the ScanKey machinery. Perhaps
someone will be motivated to fix that someday...
|
|
|
|
| |
routines that are now dead code.
|
|
|
|
|
|
|
|
| |
work under a wider range of scenarios than it did --- it formerly did not
handle a multi-pass inner scan, nor cases in which the inner scan's
indxqualorig or non-index qual contained outer var references. I am not
sure that these limitations could be hit in the existing optimizer, but
they need to be fixed for future expansion.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> >
> > was implemented by Jan Wieck.
> > His work is for ascending order cases.
> >
> > Here is a patch to prevent sorting also in descending
> > order cases.
> > Because I had already changed _bt_first() to position
> > backward correctly before v6.5,this patch would work.
> >
Hiroshi Inoue
Inoue@tpf.co.jp
|
|
|
|
| |
expression_tree_mutator.
|
|
|
|
| |
Centralize att_disbursion readout logic.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
multi-scan indexscan plans; it tried to use the same table-to-index
attribute mapping for all the scans, even if they used different indexes.
It would klugily work as long as OR indexquals never used multikey indexes,
but that's not likely to hold up much longer...
|
|
|
|
| |
walking logic with expression_tree_walker/mutator calls.
|
|
|
|
|
|
| |
to go along with expression_tree_walker. (_walker is not suitable for
routines that need to alter the tree structure significantly.) Other minor
cleanups in clauses.c.
|
| |
|
|
|
|
|
|
| |
Also, move responsibility for calling vc_abort into main xact.c list of
things-to-call-at-abort. What in the world was it doing down inside of
TransactionIdAbort()?
|
|
|
|
| |
was recording a disbursion of 0, not the correct value 1/numberOfRows.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
hashjoinable clause, not one path for a randomly-chosen element of each
set of clauses with the same join operator. That is, if you wrote
SELECT ... WHERE t1.f1 = t2.f2 and t1.f3 = t2.f4,
and both '=' ops were the same opcode (say, all four fields are int4),
then the system would either consider hashing on f1=f2 or on f3=f4,
but it would *not* consider both possibilities. Boo hiss.
Also, revise estimation of hashjoin costs to include a penalty when the
inner join var has a high disbursion --- ie, the most common value is
pretty common. This tends to lead to badly skewed hash bucket occupancy
and way more comparisons than you'd expect on average.
I imagine that the cost calculation still needs tweaking, but at least
it generates a more reasonable plan than before on George Young's example.
|
|
|
|
| |
constant-coercion expression in the rules test.
|
|
|
|
|
| |
constants, not only string constants, at parse time. Get rid of
parser_typecast2(), which is bogus and redundant...
|
|
|
|
|
| |
use Autoconf-approved method of testing for predefined symbols, and move
it down to where we know what compiler to run and how to run it.
|
|
|
|
| |
in MVCC environment. I do not trust this until Vadim says it's OK...
|
| |
|
|
|
|
|
|
|
|
|
| |
(it should just call the given operator, not look up an = operator).
Fix intltsel() so that all numeric data types are converted to double
before trying to estimate where the given comparison value is in the
known range of column values. intltsel() still needs work, or replacement,
for non-numeric data types ... but for nonintegral numeric types it
should now be delivering reasonable estimates.
|
| |
|
|
|
|
|
|
|
| |
configure.in to determine if a system is ELF or not. Note that some
of the tests earlier may be redundant but I took the safest route.
D'Arcy J.M. Cain
|
|
|
|
|
|
|
|
|
|
| |
neqsel now behave as per my suggestions in pghackers a few days ago.
selectivity for < > <= >= should work OK for integral types as well, but
still need work for nonintegral types. Since these routines have never
actually executed before :-(, this may result in some significant changes
in the optimizer's choices of execution plans. Let me know if you see
any serious misbehavior.
CAUTION: THESE CHANGES REQUIRE INITDB. pg_statistic table has changed.
|
|
|
|
| |
every time I tweak the optimizer...
|
|
|
|
| |
and target databases are of versions it knows about.
|
| |
|
| |
|
|
|
|
| |
update temp tables with this setting.
|
|
|
|
|
| |
logic in indxpath.c, avoid generation of redundant indexscan paths for the
same relation and index.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
for example in the regression test database, try
select * from tenk1 t1, tenk1 t2 where t1.unique1 = t2.unique2;
6.5 has this same bug ...
|