- 21 11月, 2005 1 次提交
-
-
由 Tom Lane 提交于
the convenience of tuptoaster.c and is no longer needed, so may as well get rid of some small amount of overhead.
-
- 15 10月, 2005 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 07 5月, 2005 1 次提交
-
-
由 Tom Lane 提交于
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.
-
- 01 1月, 2005 1 次提交
-
-
由 PostgreSQL Daemon 提交于
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 8月, 2004 2 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
- 04 2月, 2004 1 次提交
-
-
由 Tom Lane 提交于
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.
-
- 30 11月, 2003 1 次提交
-
-
由 PostgreSQL Daemon 提交于
$Header: -> $PostgreSQL Changes ...
-
- 04 8月, 2003 2 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
- 26 7月, 2003 1 次提交
-
-
由 Tom Lane 提交于
-
- 29 4月, 2003 1 次提交
-
-
由 Tom Lane 提交于
context sloppiness, some other things. Includes Neil's mopup patch of 22-Apr.
-
- 28 3月, 2003 1 次提交
-
-
由 Bruce Momjian 提交于
(materialization into a tuple store) discussed on pgsql-hackers earlier. I've updated the documentation and the regression tests. Notes on the implementation: - I needed to change the tuple store API slightly -- it assumes that it won't be used to hold data across transaction boundaries, so the temp files that it uses for on-disk storage are automatically reclaimed at end-of-transaction. I added a flag to tuplestore_begin_heap() to control this behavior. Is changing the tuple store API in this fashion OK? - in order to store executor results in a tuple store, I added a new CommandDest. This works well for the most part, with one exception: the current DestFunction API doesn't provide enough information to allow the Executor to store results into an arbitrary tuple store (where the particular tuple store to use is chosen by the call site of ExecutorRun). To workaround this, I've temporarily hacked up a solution that works, but is not ideal: since the receiveTuple DestFunction is passed the portal name, we can use that to lookup the Portal data structure for the cursor and then use that to get at the tuple store the Portal is using. This unnecessarily ties the Portal code with the tupleReceiver code, but it works... The proper fix for this is probably to change the DestFunction API -- Tom suggested passing the full QueryDesc to the receiveTuple function. In that case, callers of ExecutorRun could "subclass" QueryDesc to add any additional fields that their particular CommandDest needed to get access to. This approach would work, but I'd like to think about it for a little bit longer before deciding which route to go. In the mean time, the code works fine, so I don't think a fix is urgent. - (semi-related) I added a NO SCROLL keyword to DECLARE CURSOR, and adjusted the behavior of SCROLL in accordance with the discussion on -hackers. - (unrelated) Cleaned up some SGML markup in sql.sgml, copy.sgml Neil Conway
-
- 09 3月, 2003 1 次提交
-
-
由 Tom Lane 提交于
entire contents of the subplan into the tuplestore before we can return any tuples. Instead, the tuplestore holds what we've already read, and we fetch additional rows from the subplan as needed. Random access to the previously-read rows works with the tuplestore, and doesn't affect the state of the partially-read subplan. This is a step towards fixing the problems with cursors over complex queries --- we don't want to stick in Materialize nodes if they'll prevent quick startup for a cursor.
-
- 13 11月, 2002 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 11 11月, 2002 1 次提交
-
-
由 Bruce Momjian 提交于
to MemSet is a performance boost.
-
- 10 11月, 2002 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 12 8月, 2002 1 次提交
-
-
由 Tom Lane 提交于
to make a reasonable attempt at accounting for palloc overhead, not just the requested size of each memory chunk. Since in many scenarios this will make for a significant reduction in the amount of space acquired, partially compensate by doubling the default value of SORT_MEM to 1Mb. Per discussion in pgsql-general around 9-Jun-2002..
-
- 21 6月, 2002 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 28 10月, 2001 1 次提交
-
-
由 Bruce Momjian 提交于
spacing. Also adds space for one-line comments.
-
- 25 10月, 2001 1 次提交
-
-
由 Bruce Momjian 提交于
tests pass.
-
- 22 3月, 2001 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 25 1月, 2001 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 19 6月, 2000 1 次提交
-
-
由 Tom Lane 提交于
materialized tupleset is small enough) instead of a temporary relation. This was something I was thinking of doing anyway for performance, and Jan says he needs it for TOAST because he doesn't want to cope with toasting noname relations. With this change, the 'noname table' support in heap.c is dead code, and I have accordingly removed it. Also clean up 'noname' plan handling in planner --- nonames are either sort or materialize plans, and it seems less confusing to handle them separately under those names.
-