| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
| |
libxml as the detail message.
As per <http://archives.postgresql.org/pgsql-hackers/2006-12/msg01087.php>.
For converting error codes to messages, we only need to cover those codes
that we raise ourselves now.
|
|
|
|
|
|
| |
FAMILY; and add FAMILY option to CREATE OPERATOR CLASS to allow adding a
class to a pre-existing family. Per previous discussion. Man, what a
tedious lot of cutting and pasting ...
|
|
|
|
|
| |
values. Point to /include/ntstatus.h for an exception list, rather than
a URL.
|
|
|
|
| |
than hex codes, using FormatMessage().
|
|
|
|
|
|
|
|
|
|
| |
which I had removed in the first cut of the EquivalenceClass rewrite to
simplify that patch a little. But it's still important --- in a four-way
join problem mergejoinscansel() was eating about 40% of the planning time
according to gprof. Also, improve the EquivalenceClass code to re-use
join RestrictInfos rather than generating fresh ones for each join
considered. This saves some memory space but more importantly improves
the effectiveness of caching planning info in RestrictInfos.
|
| |
|
|
|
|
| |
exception value in hex, and give a URL where the value can be looked-up.
|
|
|
|
|
|
|
|
|
|
|
|
| |
columns procost and prorows, to allow simple user adjustment of the estimated
cost of a function call, as well as control of the estimated number of rows
returned by a set-returning function. We might eventually wish to extend this
to allow function-specific estimation routines, but there seems to be
consensus that we should try a simple constant estimate first. In particular
this provides a relatively simple way to control the order in which different
WHERE clauses are applied in a plan node, which is a Good Thing in view of the
fact that the recent EquivalenceClass planner rewrite made that much less
predictable than before.
|
|
|
|
| |
a couple of syscache lookups in make_pathkey_from_sortinfo().
|
|
|
|
|
|
|
| |
provide just a boolean 'amcanorder', instead of fields that specify the
sort operator strategy numbers. We have decided to require ordering-capable
AMs to use btree-compatible strategy numbers, so the old fields are
overkill (and indeed misleading about what's allowed).
|
|
|
|
| |
pgsql-patches discussion of September 20, 2006. Bump the catversion.
|
|
|
|
| |
Backpatch to 8.2.X for new initdbs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
representation of equivalence classes of variables. This is an extensive
rewrite, but it brings a number of benefits:
* planner no longer fails in the presence of "incomplete" operator families
that don't offer operators for every possible combination of datatypes.
* avoid generating and then discarding redundant equality clauses.
* remove bogus assumption that derived equalities always use operators
named "=".
* mergejoins can work with a variety of sort orders (e.g., descending) now,
instead of tying each mergejoinable operator to exactly one sort order.
* better recognition of redundant sort columns.
* can make use of equalities appearing underneath an outer join.
|
|
|
|
|
|
|
| |
currentMarkData from IndexScanDesc to the opaque structs for the
AMs that need this information (currently gist and hash).
Patch from Heikki Linnakangas, fixes by Neil Conway.
|
| |
|
|
|
|
| |
rather than a value too high.
|
|
|
|
| |
function is_log_level_output(), for code clarity.
|
|
|
|
| |
function xmlagg.
|
|
|
|
| |
for its header comment.
|
|
|
|
|
| |
with new GUC parameter "xmlbinary" that controls the output encoding, as
per SQL/XML standard.
|
|
|
|
|
| |
declarations are ignored and removed, in binary mode they are honored as
specified by the XML standard.
|
|
|
|
|
| |
for aggregates. This is OK for current uses but could burn somebody
someday...
|
|
|
|
| |
pending fsyncs during DROP DATABASE. Obviously necessary in hindsight :-(
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is deleted. A backend about to unlink a file now sends a "revoke fsync"
request to the bgwriter to make it clean out pending fsync requests. There
is still a race condition where the bgwriter may try to fsync after the unlink
has happened, but we can resolve that by rechecking the fsync request queue
to see if a revoke request arrived meanwhile. This eliminates the former
kluge of "just assuming" that an ENOENT failure is okay, and lets us handle
the fact that on Windows it might be EACCES too without introducing any
questionable assumptions. After an idea of mine improved by Magnus.
The HEAD patch doesn't apply cleanly to 8.2, but I'll see about a back-port
later. In the meantime this could do with some testing on Windows; I've been
able to force it through the code path via ENOENT, but that doesn't prove that
it actually fixes the Windows problem ...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The implementation is somewhat ugly logic-wise, but I don't see an
easy way to make it more concise.
When writing this, I noticed that my previous implementation of
width_bucket() doesn't handle NaN correctly:
postgres=# select width_bucket('NaN', 1, 5, 5);
width_bucket
--------------
6
(1 row)
AFAICS SQL:2003 does not define a NaN value, so it doesn't address how
width_bucket() should behave here. The patch changes width_bucket() so
that ereport(ERROR) is raised if NaN is specified for the operand or the
lower or upper bounds to width_bucket(). For float8, NaN is disallowed
for any of the floating-point inputs, and +/- infinity is disallowed
for the histogram bounds (but allowed for the operand).
Update docs and regression tests, bump the catversion.
|
|
|
|
|
|
|
|
|
|
| |
it was checking a pg_constraint OID instead of pg_class OID, resulting in
"relation with OID nnnnn does not exist" failures for anyone who wasn't
owner of the table being examined. Per bug #2848 from Laurence Rowe.
Note: for existing 8.2 installations a simple version update won't fix this;
the easiest fix is to CREATE OR REPLACE this view with the corrected
definition.
|
| |
|
|
|
|
|
|
| |
accessing it, like DROP DATABASE. This allows the regression tests to pass
with autovacuum enabled, which open the gates for finally enabling autovacuum
by default.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
standard convention the 21st century runs from 2001-2100, not 2000-2099,
so make it work like that. Per bug #2885 from Akio Iwaasa.
Backpatch to 8.2, but no further, since this is really a definitional
change; users of older branches are probably more interested in stability.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
hold true for operators in a btree operator family. This is mostly to
clarify my own thinking about what the planner can assume for optimization
purposes. (blowing dust off an old abstract-algebra textbook...)
|
|
|
|
|
| |
coercion to type xml was a mistake. Escape values so they are valid
XML character data.
|
|
|
|
|
|
|
|
|
|
|
| |
(or other types of pg_class entry): the function pgstat_vacuum_tabstat,
invoked during VACUUM startup, had runtime proportional to the number of
stats table entries times the number of pg_class rows; in other words
O(N^2) if the stats collector's information is reasonably complete.
Replace list searching with a hash table to bring it back to O(N)
behavior. Per report from kim at myemma.com.
Back-patch as far as 8.1; 8.0 and before use different coding here.
|
|
|
|
| |
expressions/functions.
|
|
|
|
| |
ORDER BY.
|
|
|
|
| |
So far only tested by hacking the planner ...
|
|
|
|
|
| |
our own printing dance. This does a better job of quoting and escaping the
values.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
research.
|
|
|
|
|
|
| |
nattr field, and rename the field.
Heikki Linnakangas
|
|
|
|
| |
Bill Moran
|
|
|
|
|
|
|
|
|
|
| |
management. The paper clearly describes many of the ideas embodied in
our current hashing code, but as far as I could find out there is not
a direct code heritage. (Mike Olsen recalls discussion of this paper
at Postgres meetings but believes it "informed the Postgres implementation
probably just at the design level". Margo herself says she wasn't
involved with Postgres' hash code.) Credit where credit is due 'n all
that, even if fifteen years after the fact.
|
|
|
|
|
|
|
|
|
|
|
|
| |
per-column options for btree indexes. The planner's support for this is still
pretty rudimentary; it does not yet know how to plan mergejoins with
nondefault ordering options. The documentation is pretty rudimentary, too.
I'll work on improving that stuff later.
Note incompatible change from prior behavior: ORDER BY ... USING will now be
rejected if the operator is not a less-than or greater-than member of some
btree opclass. This prevents less-than-sane behavior if an operator that
doesn't actually define a proper sort ordering is selected.
|