| Commit message (Collapse) | Author | Age |
... | |
| |
|
|
|
|
|
|
| |
name, path does not exist), rather than returning nothing.
Backpatch to 8.1.X.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that the Mackert-Lohmann formula applies across all the repetitions of the
nestloop, not just each scan independently. We use the M-L formula to
estimate the number of pages fetched from the index as well as from the table;
that isn't what it was designed for, but it seems reasonably applicable
anyway. This makes large numbers of repetitions look much cheaper than
before, which accords with many reports we've received of overestimation
of the cost of a nestloop. Also, change the index access cost model to
charge random_page_cost per index leaf page touched, while explicitly
not counting anything for access to metapage or upper tree pages. This
may all need tweaking after we get some field experience, but in simple
tests it seems to be giving saner results than before. The main thing
is to get the infrastructure in place to let cost_index() and amcostestimate
functions take repeated scans into account at all. Per my recent proposal.
Note: this patch changes pg_proc.h, but I did not force initdb because
the changes are basically cosmetic --- the system does not look into
pg_proc to decide how to call an index amcostestimate function, and
there's no way to call such a function from SQL at all.
|
| |
|
|
|
|
| |
Backpatch to 8.1.X.
|
|
|
|
| |
Synced parser.
|
|
|
|
| |
Per my proposal a few days ago.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cost_nonsequential_access() is really totally inappropriate for its only
remaining use, namely estimating I/O costs in cost_sort(). The routine
was designed on the assumption that disk caching might eliminate the need
for some re-reads on a random basis, but there's nothing very random in
that sense about sort's access pattern --- it'll always be picking up the
oldest outputs. If we had a good fix on the effective cache size we
might consider charging zero for I/O unless the sort temp file size
exceeds it, but that's probably putting much too much faith in the
parameter. Instead just drop the logic in favor of a fixed compromise
between seq_page_cost and random_page_cost per page of sort I/O.
|
|
|
|
| |
making it volatile.
|
|
|
|
| |
executed, like it did for 8.1.X.
|
|
|
|
|
|
| |
This shouldn't affect simple indexscans much, while for bitmap scans that
are touching a lot of index rows, this seems to bring the estimates more
in line with reality. Per recent discussion.
|
|
|
|
|
|
|
|
| |
assumed that a sequential page fetch has cost 1.0. This patch doesn't
in itself change the system's behavior at all, but it opens the door to
people adopting other units of measurement for EXPLAIN costs. Also, if
we ever decide it's worth inventing per-tablespace access cost settings,
this change provides a workable intellectual framework for that.
|
|
|
|
| |
the query.
|
|
|
|
|
|
|
|
|
|
| |
for LC_MESSAGES; instead, just press forward, leaving the effective setting
at 'C'. There is not any very good reason to complain when we are going
to replace the value soon with whatever postgresql.conf says. This change
should solve the occasionally-reported problem of initdb failing with
'failed to initialize lc_messages'; the current theory is that that is
a reflection of either wrong LANG/LC_MESSAGES or completely broken locale
support.
|
|
|
|
|
| |
HAVE_INT64_TIMESTAMP was mentioning PG_CONTROL_VERSION instead.
Victor Snezhko
|
|
|
|
| |
http://archives.postgresql.org/pgsql-hackers/2006-05/msg00002.php
|
|
|
|
| |
E'...' syntax for strings in order to track the backend.
|
|
|
|
|
|
| |
and there's only one place that's a kluge, ie, appendStringLiteralConn.
Note that pg_dump itself doesn't use appendStringLiteralConn, so its
behavior is not affected; only the other utility programs care.
|
|
|
|
| |
NOT the thing to use here.
|
|
|
|
|
| |
the server. Per discussion, there seems no point in a waiting period
before making this required.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
o turns off escape_string_warning in pg_dumpall.c
o optionally use E'' for \password (undocumented option?)
o honor standard_conforming-strings for \copy (but not
support literal E'' strings)
o optionally use E'' for \d commands
o turn off escape_string_warning for createdb, createuser,
droplang
|
| |
|
|
|
|
| |
resulting from SoC.
|
|
|
|
| |
in every shared library.
|
|
|
|
|
|
|
|
|
|
| |
as this seems only likely to create headaches for module developers. Put
the macro in the pre-existing fmgr.h file instead. Avoid being too cute
about how many fields we can cram into a word, and avoid trying to fetch
from a library we've already unlinked.
Along the way, it occurred to me that the magic block really ought to be
'const' so it can be stored in the program text area. Do the same for
the existing data blocks for PG_FUNCTION_INFO_V1 functions.
|
|
|
|
|
| |
across multiple loops, get rid of the shaky assumption that exactly one
tuple is returned per node iteration.
|
| |
|
| |
|
|
|
|
|
| |
This is just the minimal necessary change; we might want to adopt
later PPPort output instead.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It now only checks four things:
Major version number (7.4 or 8.1 for example)
NAMEDATALEN
FUNC_MAX_ARGS
INDEX_MAX_KEYS
The three constants were chosen because:
1. We document them in the config page in the docs
2. We mark them as changable in pg_config_manual.h
3. Changing any of these will break some of the more popular modules:
FUNC_MAX_ARGS changes fmgr interface, every module uses this NAMEDATALEN
changes syscache interface, every PL as well as tsearch uses this
INDEX_MAX_KEYS breaks tsearch and anything using GiST.
Martijn van Oosterhout
|
|
|
|
| |
Martijn van Oosterhout
|
|
|
|
| |
demonstrating that its intent wasn't obvious.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
---------------------------------------------------------------------------
Add dynamic record inspection to PL/PgSQL, useful for generic triggers:
tval2 := r.(cname);
or
columns := r.(*);
Titus von Boxberg
|
|
|
|
| |
into HEAD.
|
|
|
|
| |
Simon Riggs
|
|
|
|
| |
Qingqing Zhou
|
|
|
|
|
|
|
|
| |
#define inline __inline
Backpatch to 8.1.X.
Hiroshi Saito
|
|
|
|
|
|
|
|
|
|
| |
tval2 := r.(cname);
or
columns := r.(*);
Titus von Boxberg
|
| |
|
|
|
|
| |
Joachim Wieland
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
---------------------------------------------------------------------------
Delay write of pg_stats file to once every five minutes, during
shutdown, or when requested by a backend:
It changes so the file is only written once every 5 minutes (changeable
of course, I just picked something) instead of once every half second.
It's still written when the stats collector shuts down, just as before.
And it is now also written on backend request. A backend requests a
rewrite by simply sending a special stats message. It operates on the
assumption that the backends aren't actually going to read the
statistics file very often, compared to how frequent it's written today.
Magnus Hagander
|
| |
|
|
|
|
|
| |
with a fresh local value for each invocation, to avoid unexpected sharing
violations. Per recent -hackers discussion.
|
|
|
|
|
|
| |
If user picksplit on n-th column generate equals
left and right unions then it calls picksplit on n+1-th
column.
|
|
|
|
| |
From Andreas Seltenreich <andreas+pg@gate450.dyndns.org>
|
|
|
|
| |
wasn't exported by exports.txt. Ooops. Per buildfarm results.
|
|
|
|
|
|
|
|
|
| |
and standard_conforming_strings; likewise for the other client programs
that need it. As per previous discussion, a pg_dump dump now conforms
to the standard_conforming_strings setting of the source database.
We don't use E'' syntax in the dump, thereby improving portability of
the SQL. I added a SET escape_strings_warning = off command to keep
the dumps from getting a lot of back-chatter from that.
|
|
|
|
|
|
|
| |
Per Coverity bug #304. Thanks to Martijn van Oosterhout for reporting it.
Zero out the pointer fields of PGresult so that these mistakes are more
easily catched, per discussion.
|