- 20 4月, 2012 2 次提交
-
-
由 Tom Lane 提交于
This patch adjusts the treatment of parameterized paths so that all paths with the same parameterization (same set of required outer rels) for the same relation will have the same rowcount estimate. We cache the rowcount estimates to ensure that property, and hopefully save a few cycles too. Doing this makes it practical for add_path_precheck to operate without a rowcount estimate: it need only assume that paths with different parameterizations never dominate each other, which is close enough to true anyway for coarse filtering, because normally a more-parameterized path should yield fewer rows thanks to having more join clauses to apply. In add_path, we do the full nine yards of comparing rowcount estimates along with everything else, so that we can discard parameterized paths that don't actually have an advantage. This fixes some issues I'd found with add_path rejecting parameterized paths on the grounds that they were more expensive than not-parameterized ones, even though they yielded many fewer rows and hence would be cheaper once subsequent joining was considered. To make the same-rowcounts assumption valid, we have to require that any parameterized path enforce *all* join clauses that could be obtained from the particular set of outer rels, even if not all of them are useful for indexing. This is required at both base scans and joins. It's a good thing anyway since the net impact is that join quals are checked at the lowest practical level in the join tree. Hence, discard the original rather ad-hoc mechanism for choosing parameterization joinquals, and build a better one that has a more principled rule for when clauses can be moved. The original rule was actually buggy anyway for lack of knowledge about which relations are part of an outer join's outer side; getting this right requires adding an outer_relids field to RestrictInfo.
-
由 Peter Eisentraut 提交于
Like with SGML files, using tabs in these files is confusing and unnecessary.
-
- 18 4月, 2012 10 次提交
-
-
由 Robert Haas 提交于
This has been wrong for a really long time. We don't use two-phase locking to protect against serialization anomalies. Per discussion on pgsql-hackers about 2011-03-07; original report by Dan Ports.
-
由 Robert Haas 提交于
Commit 8e5ac74c tried to do this renaming, but I relied on gcc to tell me where I needed to make changes, instead of grep. Noted by Jeff Davis.
-
由 Robert Haas 提交于
The previous code could cause a backend crash after BEGIN; SAVEPOINT a; LOCK TABLE foo (interrupted by ^C or statement timeout); ROLLBACK TO SAVEPOINT a; LOCK TABLE foo, and might have leaked strong-lock counts in other situations. Report by Zoltán Böszörményi; patch review by Jeff Davis.
-
由 Robert Haas 提交于
Noah Misch spotted the fact that the old comment is in fact incorrect, due to memory ordering hazards.
-
由 Robert Haas 提交于
Previously, we used SetBufferCommitInfoNeedsSave, but that's really intended for dirty-marks we can theoretically afford to lose, such as hint bits. As for 9.2, the PD_ALL_VISIBLE mustn't be lost in this way, since we could then end up with a heap page that isn't all-visible and a visibility map page that is all visible, causing index-only scans to return wrong answers.
-
由 Robert Haas 提交于
Noah Misch
-
由 Robert Haas 提交于
Mostly, this consists of adding support for fields which exist in the structure but aren't handled by copy/equal/outfuncs; but the create foreign table case can actually produce garbage output. Noah Misch
-
由 Robert Haas 提交于
Fujii Masao
-
由 Peter Eisentraut 提交于
Previously, the use of the optional key word WITH was not supported. Josh Kupershmidt
-
由 Andrew Dunstan 提交于
A number of utility programs were rather careless about paremeters that can be set via both an option argument and a positional argument. This leads to results which can violate the Principal Of Least Astonishment. These changes refuse to use positional arguments to override settings that have been made via positional arguments. The changes are backpatched to all live branches.
-
- 17 4月, 2012 2 次提交
-
-
由 Heikki Linnakangas 提交于
When using synchronous replication, we waited for the commit record to be replicated, but if we our transaction didn't write any other WAL records, that's not required because we don't even flush the WAL locally to disk in that case. This lead to long waits when committing a transaction that only modified a temporary table. Bug spotted by Thom Brown.
-
由 Peter Eisentraut 提交于
-
- 16 4月, 2012 4 次提交
-
-
由 Peter Eisentraut 提交于
Kyotaro HORIGUCHI
-
由 Heikki Linnakangas 提交于
The header file is needed by any module that wants to use the PL/pgSQL instrumentation plugin interface. Most notably, the pldebugger plugin needs this. With this patch, it can be built using pgxs, without having the full server source tree available.
-
由 Peter Eisentraut 提交于
Clarify that nrows() is the number of rows processed, versus the number of rows returned, which can be obtained using len. Also add tests about that.
-
由 Peter Eisentraut 提交于
The result object methods colnames() etc. would crash when called after a command that did not produce a result set. Now they throw an exception. discovery and initial patch by Jean-Baptiste Quenot
-
- 15 4月, 2012 1 次提交
-
-
由 Tatsuo Ishii 提交于
message. They are already implemented in the source code. Suggestions about the message formatting from Tom Lane.
-
- 14 4月, 2012 12 次提交
-
-
由 Robert Haas 提交于
Fujii Masao, per discussion on pgsql-hackers
-
由 Robert Haas 提交于
The output of the new pg_xlog_location_diff function is of type numeric, since it could theoretically overflow an int8 due to signedness; this provides a convenient way to format such values. Fujii Masao, with some beautification by me.
-
由 Tatsuo Ishii 提交于
discussion of hackers list on 2012/3/10 "missing description initdb manual".
-
由 Peter Eisentraut 提交于
Remove lots of outdated information that is duplicated by the better-maintained SGML documentation. In particular, remove the outdated listing of contrib modules. Update the installation instructions to mention CREATE EXTENSION, but don't go into too much detail.
-
由 Peter Eisentraut 提交于
-
由 Peter Eisentraut 提交于
Etsuro Fujita
-
由 Robert Haas 提交于
-
由 Tom Lane 提交于
So far as I can tell, it is no longer possible for this heuristic to do anything useful, because the new weaker definition of have_relevant_joinclause means that any relation with a joinclause must be considered joinable to at least one other relation. It would still be possible for the code block to be entered, for example if there are join order restrictions that prevent any join of the current level from being formed; but in that case it's just a waste of cycles to attempt to form cartesian joins, since the restrictions will still apply. Furthermore, IMO the existence of this code path can mask bugs elsewhere; we would have noticed the problem with cartesian joins a lot sooner if this code hadn't compensated for it in the simplest case. Accordingly, let's remove it and see what happens. I'm committing this separately from the prerequisite changes in have_relevant_joinclause, just to make the question easier to revisit if there is some fault in my logic.
-
由 Tom Lane 提交于
We should be willing to cross-join two small relations if that allows us to use an inner indexscan on a large relation (that is, the potential indexqual for the large table requires both smaller relations). This worked in simple cases but fell apart as soon as there was a join clause to a fourth relation, because the existence of any two-relation join clause caused the planner to not consider clauseless joins between other base relations. The added regression test shows an example case adapted from a recent complaint from Benoit Delbosc. Adjust have_relevant_joinclause, have_relevant_eclass_joinclause, and has_relevant_eclass_joinclause to consider that a join clause mentioning three or more relations is sufficient grounds for joining any subset of those relations, even if we have to do so via a cartesian join. Since such clauses are relatively uncommon, this shouldn't affect planning speed on typical queries; in fact it should help a bit, because the latter two functions in particular get significantly simpler. Although this is arguably a bug fix, I'm not going to risk back-patching it, since it might have currently-unforeseen consequences.
-
由 Peter Eisentraut 提交于
Per mailing list discussion, we would like to keep the bytea functions parallel to the text functions, so rename bytea_agg to string_agg, which already exists for text. Also, to satisfy the rule that we don't want aggregate functions of the same name with a different number of arguments, add a delimiter argument, just like string_agg for text already has.
-
由 Peter Eisentraut 提交于
-
由 Robert Haas 提交于
Christoph Berg
-
- 13 4月, 2012 2 次提交
-
-
由 Robert Haas 提交于
-
由 Robert Haas 提交于
The previous comment described how things worked in PostgreSQL 8.2 and prior.
-
- 12 4月, 2012 3 次提交
-
-
由 Tom Lane 提交于
Thom Brown
-
由 Tom Lane 提交于
cost_index's method for estimating per-tuple costs of evaluating filter conditions (a/k/a qpquals) was completely wrong in the presence of derived indexable conditions, such as range conditions derived from a LIKE clause. This was largely masked in common cases as a result of all simple operator clauses having about the same costs, but it could show up in a big way when dealing with functional indexes containing expensive functions, as seen for example in bug #6579 from Istvan Endredy. Rejigger the calculation to give sane answers when the indexquals aren't a subset of the baserestrictinfo list. As a side benefit, we now do the calculation properly for cases involving join clauses (ie, parameterized indexscans), which we always overestimated before. There are still cases where this is an oversimplification, such as clauses that can be dropped because they are implied by a partial index's predicate. But we've never accounted for that in cost estimates before, and I'm not convinced it's worth the cycles to try to do so.
-
由 Tom Lane 提交于
Previously we attempted to throw an error or at least warning for missing schemas, but this was done inconsistently because of implementation restrictions (in many cases, GUC settings are applied outside transactions so that we can't do system catalog lookups). Furthermore, there were exceptions to the rule even in the beginning, and we'd been poking more and more holes in it as time went on, because it turns out that there are lots of use-cases for having some irrelevant items in a common search_path value. It seems better to just adopt a philosophy similar to what's always been done with Unix PATH settings, wherein nonexistent or unreadable directories are silently ignored. This commit also fixes the documentation to point out that schemas for which the user lacks USAGE privilege are silently ignored. That's always been true but was previously not documented. This is mostly in response to Robert Haas' complaint that 9.1 started to throw errors or warnings for missing schemas in cases where prior releases had not. We won't adopt such a significant behavioral change in a back branch, so something different will be needed in 9.1.
-
- 11 4月, 2012 4 次提交
-
-
由 Alvaro Herrera 提交于
postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.
-
由 Tom Lane 提交于
This definition is convenient when applying the function to the reltablespace column of pg_class, since that's what zero means there; and it doesn't interfere with any other plausible use of the function. Per gripe from Bruce Momjian.
-
由 Bruce Momjian 提交于
default tablespace, but part of a database that is in a user-defined tablespace. Caused "file not found" error during upgrade. Per bug report from Ants Aasma. Backpatch to 9.1 and 9.0.
-
由 Peter Eisentraut 提交于
Since xgettext provides options to do this now, we might as well use them.
-