- 27 Jun, 2006 1 commit
-
-
Tom Lane authored
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.
-
- 23 May, 2006 1 commit
-
-
Tom Lane authored
and transaction visibility fields of tuples being sorted. These are always uninteresting in a tuple being sorted (if the fields were actually selected, they'd have been pulled out into user columns beforehand). This saves about 24 bytes per row being sorted, which is a useful savings for any but the widest of sort rows. Per recent discussion.
-
- 10 Mar, 2006 1 commit
-
-
Tom Lane authored
case where we run low on array slots before we run low on memory is much more probable than I had thought, and so it's important to treat each tape fairly in that case. To fix this, track per-tape slot allocations just like we track per-tape space allocation. Also, in the FINALMERGE code path avoid scanning all the input tapes when we really only need to read from one. This should fix poor behavior with very large work_mem as exhibited by Stefan Kaltenbrunner. I didn't do anything about putting an upper bound on the number of tapes, but maybe we should still consider that.
-
- 08 Mar, 2006 1 commit
-
-
Tom Lane authored
tapes) for each merge step. This will give us some idea of how effective the merge distribution algorithm is.
-
- 07 Mar, 2006 1 commit
-
-
Tom Lane authored
we are doing the final merge pass on-the-fly, and not writing the data back onto a 'tape', the number of free blocks in the tape set will become large, leading to a lot of time wasted in ltsReleaseBlock(). There is really no need to track the free blocks anymore in this state, so add a simple shutoff switch. Per report from Stefan Kaltenbrunner.
-
- 05 Mar, 2006 1 commit
-
-
Bruce Momjian authored
-
- 04 Mar, 2006 1 commit
-
-
Tom Lane authored
we'll go over to disk-based sort if we reach that limit. This fixes Stefan Kaltenbrunner's observation that sorting can suffer an 'invalid memory alloc request size' failure when sort_mem is set large enough. It's unfortunately not so easy to fix in 8.1 ...
-
- 26 Feb, 2006 1 commit
-
-
Tom Lane authored
each tuple, as per my proposal of several days ago. Also, clean up sort memory management by keeping all working data in a separate memory context, and refine the handling of low-memory conditions.
-
- 19 Feb, 2006 2 commits
-
-
Tom Lane authored
-
Tom Lane authored
with fixed merge order (fixed number of "tapes") was based on obsolete assumptions, namely that tape drives are expensive. Since our "tapes" are really just a couple of buffers, we can have a lot of them given adequate workspace. This allows reduction of the number of merge passes with consequent savings of I/O during large sorts. Simon Riggs with some rework by Tom Lane
-
- 05 Jan, 2006 1 commit
-
-
Bruce Momjian authored
-
- 22 Nov, 2005 1 commit
-
-
Bruce Momjian authored
comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
-
- 20 Nov, 2005 1 commit
-
-
Tom Lane authored
the convenience of tuptoaster.c and is no longer needed, so may as well get rid of some small amount of overhead.
-
- 25 Oct, 2005 1 commit
-
-
Bruce Momjian authored
-
- 18 Oct, 2005 1 commit
-
-
Tom Lane authored
Per request from Marc.
-
- 15 Oct, 2005 1 commit
-
-
Bruce Momjian authored
-
- 03 Oct, 2005 1 commit
-
-
Tom Lane authored
sort operations. Per recent discussion. Simon Riggs and Tom Lane.
-
- 23 Sep, 2005 1 commit
-
-
Tom Lane authored
-
- 25 May, 2005 1 commit
-
-
Bruce Momjian authored
them, the executation behavior could be unexpected.
-
- 06 May, 2005 1 commit
-
-
Tom Lane authored
which is neither needed by nor related to that header. Remove the bogus inclusion and instead include the header in those C files that actually need it. Also fix unnecessary inclusions and bad inclusion order in tsearch2 files.
-
- 22 Mar, 2005 1 commit
-
-
Tom Lane authored
critical places in execQual. By Atsushi Ogawa; some minor cleanup by moi.
-
- 02 Feb, 2005 1 commit
-
-
Tom Lane authored
two arguments. Per suggestions from A. Ogawa.
-
- 31 Dec, 2004 1 commit
-
-
PostgreSQL Daemon authored
Tag appropriate files for rc3 Also performed an initial run through of upgrading our Copyright date to extend to 2005 ... first run here was very simple ... change everything where: grep 1996-2004 && the word 'Copyright' ... scanned through the generated list with 'less' first, and after, to make sure that I only picked up the right entries ...
-
- 29 Aug, 2004 2 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
-
- 17 Mar, 2004 1 commit
-
-
Tom Lane authored
TID (heap position). This doesn't do anything to the validity of the finished index, but by pretending to qsort() that there are no really equal keys in the sort, we can avoid performance problems with qsort implementations that have trouble with large numbers of equal keys. Patch from Manfred Koizar.
-
- 03 Feb, 2004 1 commit
-
-
Tom Lane authored
Make btree index creation and initial validation of foreign-key constraints use maintenance_work_mem rather than work_mem as their memory limit. Add some code to guc.c to allow these variables to be referenced by their old names in SHOW and SET commands, for backwards compatibility.
-
- 29 Nov, 2003 1 commit
-
-
PostgreSQL Daemon authored
$Header: -> $PostgreSQL Changes ...
-
- 12 Nov, 2003 1 commit
-
-
Tom Lane authored
pghackers proposal of 8-Nov. All the existing cross-type comparison operators (int2/int4/int8 and float4/float8) have appropriate support. The original proposal of storing the right-hand-side datatype as part of the primary key for pg_amop and pg_amproc got modified a bit in the event; it is easier to store zero as the 'default' case and only store a nonzero when the operator is actually cross-type. Along the way, remove the long-since-defunct bigbox_ops operator class.
-
- 09 Nov, 2003 1 commit
-
-
Tom Lane authored
Remove the 'strategy map' code, which was a large amount of mechanism that no longer had any use except reverse-mapping from procedure OID to strategy number. Passing the strategy number to the index AM in the first place is simpler and faster. This is a preliminary step in planned support for cross-datatype index operations. I'm committing it now since the ScanKeyEntryInitialize() API change touches quite a lot of files, and I want to commit those changes before the tree drifts under me.
-
- 17 Aug, 2003 1 commit
-
-
Tom Lane authored
datatype by array_eq and array_cmp; use this to solve problems with memory leaks in array indexing support. The parser's equality_oper and ordering_oper routines also use the cache. Change the operator search algorithms to look for appropriate btree or hash index opclasses, instead of assuming operators named '<' or '=' have the right semantics. (ORDER BY ASC/DESC now also look at opclasses, instead of assuming '<' and '>' are the right things.) Add several more index opclasses so that there is no regression in functionality for base datatypes. initdb forced due to catalog additions.
-
- 04 Aug, 2003 2 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
-
- 25 Jul, 2003 1 commit
-
-
Tom Lane authored
-
- 13 May, 2003 1 commit
-
-
Tom Lane authored
This makes no difference for existing uses, but allows SelectSortFunction() and pred_test_simple_clause() to use indexscans instead of seqscans to locate entries for a particular operator in pg_amop. Better yet, they can use the SearchSysCacheList() API to cache the search results.
-
- 13 Nov, 2002 1 commit
-
-
Bruce Momjian authored
-
- 11 Nov, 2002 1 commit
-
-
Bruce Momjian authored
to MemSet is a performance boost.
-
- 10 Nov, 2002 1 commit
-
-
Bruce Momjian authored
-
- 31 Oct, 2002 1 commit
-
-
Tom Lane authored
conform to C99's brain-dead notion of how inline functions should work.
-
- 04 Oct, 2002 1 commit
-
-
Tom Lane authored
just the significant fields of FunctionCallInfoData, rather than MemSet'ing the whole struct to zero. Unused positions in the arg[] array will thereby contain garbage rather than zeroes. This buys back some of the performance hit from increasing FUNC_MAX_ARGS. Also tweak tuplesort.c code for more speed by marking some routines 'inline'. All together these changes speed up simple sorts, like count(distinct int4column), by about 25% on a P4 running RH Linux 7.2.
-