- 29 6月, 2006 3 次提交
-
-
由 Tom Lane 提交于
-
由 Tom Lane 提交于
tuple hash table entries. This addresses the problem previously noted that use of a 'physical tlist' in the input scan node could bloat the hash table entries far beyond what the planner expects. It's a better answer than my previous thought of undoing the physical tlist optimization, because we can also remove columns that are needed to compute the aggregate functions but aren't part of the grouping column set.
-
由 Tom Lane 提交于
-
- 28 6月, 2006 9 次提交
-
-
由 Teodor Sigaev 提交于
-
由 Teodor Sigaev 提交于
* new split algorithm (as proposed in http://archives.postgresql.org/pgsql-hackers/2006-06/msg00254.php) * possible call pickSplit() for second and below columns * add spl_(l|r)datum_exists to GIST_SPLITVEC - pickSplit should check its values to use already defined spl_(l|r)datum for splitting. pickSplit should set spl_(l|r)datum_exists to 'false' (if they was 'true') to signal to caller about using spl_(l|r)datum. * support for old pickSplit(): not very optimal but correct split * remove 'bytes' field from GISTENTRY: in any case size of value is defined by it's type. * split GIST_SPLITVEC to two structures: one for using in picksplit and second - for internal use. * some code refactoring * support of subsplit to rtree opclasses TODO: add support of subsplit to contrib modules
-
由 Tom Lane 提交于
versions very unhappy, and shouldn't be there anyway.
-
由 Bruce Momjian 提交于
for every command, default to on.
-
由 Tom Lane 提交于
and batch files. Should reduce memory and I/O demands for such joins.
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
this someday, but right now it seems that posix_fadvise is immature to the point of being broken on many platforms ... and we don't have any benchmark evidence proving it's worth spending time on.
-
由 Bruce Momjian 提交于
* %Disallow changing default expression of a SERIAL column Dhanaraj M
-
由 Tom Lane 提交于
per-tuple space overhead for sorts in memory. I chose to replace the previous patch that tried to write out the bare minimum amount of data when sorting on disk; instead, just dump the MinimalTuples as-is. This wastes 3 to 10 bytes per tuple depending on architecture and null-bitmap length, but the simplification in the writetup/readtup routines seems worth it.
-
- 27 6月, 2006 10 次提交
-
-
由 Alvaro Herrera 提交于
analyzing, so that future analyze threshold calculations don't get confused. Also, make sure we correctly track the decrease of live tuples cause by deletes. Per report from Dylan Hansen, patches by Tom Lane and me.
-
由 Bruce Momjian 提交于
Greg Stark
-
由 Bruce Momjian 提交于
Dhanaraj M
-
由 Bruce Momjian 提交于
Hiroshi Saito
-
由 Tom Lane 提交于
tuples with less header overhead than a regular HeapTuple, per my recent proposal. Teach TupleTableSlot code how to deal with these. As proof of concept, change tuplestore.c to store MinimalTuples instead of HeapTuples. Future patches will expand the concept to other places where it is useful.
-
由 Bruce Momjian 提交于
directory, not in device root, for permission reasons. Backpatch to 8.1.X.
-
由 Bruce Momjian 提交于
Christopher Kings-Lynne
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
will be expanded to a list of their member fields, rather than creating a nested rowtype field as formerly. (The old behavior is still available by omitting '.*'.) This syntax is not allowed by the SQL spec AFAICS, so changing its behavior doesn't violate the spec. The new behavior is substantially more useful since it allows, for example, triggers to check for data changes with 'if row(new.*) is distinct from row(old.*)'. Per my recent proposal.
-
- 26 6月, 2006 6 次提交
-
-
由 Michael Meskes 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
relevant location.
-
由 Michael Meskes 提交于
-
由 Tom Lane 提交于
palloc() will normally round allocation requests up to the next power of 2, so make dynahash choose allocation sizes that are as close to a power of 2 as possible. Back-patch to 8.1 --- the problem exists further back, but a much larger patch would be needed and it doesn't seem worth taking any risks.
-
- 25 6月, 2006 5 次提交
-
-
由 Michael Meskes 提交于
-
由 Alvaro Herrera 提交于
opposed to what other versions apparently do, so it's not safe to print an error message. Besides, getopt_long itself already did, so it's redundant anyway.
-
由 Bruce Momjian 提交于
PGDG: > Yes. In fact the copyright belongs to credativ GmbH the company that > paid Carsten for his work. As you may or may not know I'm the CEO of > that company and can assure you that his work was contributed to the > PostgreSQL project.
-
由 Bruce Momjian 提交于
Magnus Hagander
-
由 Bruce Momjian 提交于
After updating to the latest cvs, and also building most of the addons (like PLs), the following patch is neededf for win32 + Visual C++. * Switch to use the new win32 semaphore code * Rename win32_open to pgwin32_open. win32_open collides with symbols defined in Perl. MingW didn't detect ig, MSVC did. And it's a bit too generic a name to export globally, imho... * Python defines some partially broken #pragmas in the headers when doing a debug build. Workaround. Magnus Hagander
-
- 24 6月, 2006 1 次提交
-
-
由 Tom Lane 提交于
-
- 23 6月, 2006 3 次提交
-
-
由 Michael Meskes 提交于
-
由 Tom Lane 提交于
and there was some question about its copyright status.
-
由 Tom Lane 提交于
backup history file. Bug introduced by the 8.1 change to make pg_stop_backup delete older history files. Per report from Masao Fujii.
-
- 22 6月, 2006 3 次提交
-
-
由 Tom Lane 提交于
-
由 Tom Lane 提交于
setup_win32_locks() call formerly was, to ensure that cancelConnLock is valid when it needs to be. Per Yoshiyuki Asaba.
-
由 Tom Lane 提交于
aggregates. We just disallowed that, and AFAICS there should be no other cases where direct (non-aggregated) references to input columns are allowed in a query with aggregation and no GROUP BY.
-