| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
| |
sort order down into planner, instead of handling it only at the very top
level of the planner. This fixes many things. An explicit sort is now
avoided if there is a cheaper alternative (typically an indexscan) not
only for ORDER BY, but also for the internal sort of GROUP BY. It works
even when there is no other reason (such as a WHERE condition) to consider
the indexscan. It works for indexes on functions. It works for indexes
on functions, backwards. It's just so cool...
CAUTION: I have changed the representation of SortClause nodes, therefore
THIS UPDATE BREAKS STORED RULES. You will need to initdb.
|
|
|
|
|
| |
operators (and some other places), fix rangechecks in int8 to int4
conversion (same problem we recently figured out in pg_atoi).
|
|
|
|
| |
failed on 'field < textconstant' ...
|
|
|
|
| |
Centralize att_disbursion readout logic.
|
|
|
|
|
|
|
|
|
| |
(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.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
approproate.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
> the DTK_MICROSEC case is just like the DTK_MILLISEC case.
> I think this is wrong and it ought to look like
> fsec = rint(fsec * 1000000) / 1000000;
> no?
Tom Lane.
|
|
|
|
|
|
|
|
|
|
|
|
| |
"HAS_LONG_LONG" is defined based on the assumption that
strtol() would return ERANGE if a platform does not support
64-bit integers. In current PostgreSQL 6.5 (and 6.4.2)
distribution, "HAS_LONG_LONG" is defined only if platform
is "alpha". (See include/port/alpha.h) I think the int4
range check should apply to linux_alpha as well. (I have
not tested yet but I guess this might be applicable to
newer Linux/i386 distributions which includes new GCC which
implements long int as 64-bit int.)
|
| |
|
| |
|
|
|
|
|
| |
functions, in order to work around oversight in 6.5 release: rtree
index functions haven't got any. Mea culpa ...
|
|
|
|
|
|
| |
a non-leading % would be put into the >=/<= patterns. Also, repair
longstanding confusion about whether %% means a literal %%. The SQL92
doesn't say any such thing, and textlike() knows that, but gram.y didn't.
|
|
|
|
| |
Jan
|
|
|
|
|
|
| |
198.68.123.0/27 the same when indexing them.
D'Arcy
|
|
|
|
| |
in an index doesn't have a restriction selectivity estimator.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Jan
|
| |
|
| |
|
|
|
|
|
|
| |
pg_rules to rules regression test.
Jan
|
|
|
|
|
|
|
| |
in Resdom and GroupClause so changing of resno's doesn't confuse
the grouping any more.
Jan
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The
offending code
has been removed, the action is now always dependent :-)
I suggest the following patch, to finally make trigger regression happy
again:
<<refint1.patch>>
After that you can remove the following from TODO:
Remove ERROR: check_primary_key: even number of arguments should be
specified
Trigger regression test fails
Andreas
|
|
|
|
| |
Jan
|
|
|
|
| |
real affect now.
|
|
|
|
|
|
|
|
|
|
| |
arrayfuncs.patch fixes a small bug in my previous patches for
arrays
array-regress.patch adds _bpchar and _varchar to regression tests
--
Massimo Dal Zotto
|
|
|
|
|
| |
Original code used float8out(), but the resulting exponential notation
was not handled (e.g. '3E9' was decoded as '3').
|