Hello,
Peter Eisentraut wrote:
1. post information on pgsql-general
1.a. solicit comments
2. put information page on web site
3. link from documentation to web site
I don't remember such a clear agreement either. I'm glad Chris has
written something. And posting it to -docs seems a much bette
Joe Conway <[EMAIL PROTECTED]> writes:
> This patch retains the memory consumption savings but doesn't break any
> regression tests...
I'm unconvinced that retail pfree's are the way to go. I just did some
profiling of this test case:
insert into foo values
(0,0,0),
(1,1
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
This patch retains the memory consumption savings but doesn't break any
regression tests...
I'm unconvinced that retail pfree's are the way to go. I just did some
profiling of this test case:
It's slightly depressing that there's n
Peter Eisentraut wrote:
The way I see it, combining a feature change with a code refactoring and
random white space changes is a pretty optimal way to get your patch
rejected. Please submit patches for these items separately.
OK. I split patch to two parts. Part one is refactoring of
set
Joe Conway <[EMAIL PROTECTED]> writes:
> That's undoubtedly true, and important for the case that isn't memory
> constrained (but where I'm already seeing us perform relatively well).
> But once we start the machine swapping, runtime goes in the toilet. And
> without addressing the memory leak s
Tom Lane wrote:
I wonder whether there is any reasonable way to determine which data
structures are responsible for how much space ... in my test I'm seeing
MessageContext: 822075440 total in 104 blocks; 4510280 free (1 chunks);
817565160 used
ExecutorState: 8024624 total in 3 blocks; 20592 fr
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I wonder whether there is any reasonable way to determine which data
>> structures are responsible for how much space ... in my test I'm seeing
> I was doing it by sprinkling MemoryContextStats() in various places.
Yeah, I've just been
Tom Lane wrote:
Yeah, I've just been doing that and some hand analysis too. What I get
(on a 64-bit machine) is that essentially all the space goes into
lists of A_Const lists: 32000
lists of Const lists: 32000
transformInsertRow extra lists: 14400
I think we coul
Joe Conway wrote:
> What if we built an array of A_Const nodes instead of a List? Maybe we
> could use something akin to appendStringInfo()/enlargeStringInfo() to
> build the array of nodes and enlarge it in chunks.
In inval.c you find this:
/*
* To minimize palloc traffic, we keep pending re
Joe Conway <[EMAIL PROTECTED]> writes:
> What if we built an array of A_Const nodes instead of a List? Maybe we
> could use something akin to appendStringInfo()/enlargeStringInfo() to
> build the array of nodes and enlarge it in chunks.
For lists this short I'm not sure how much of a win it'd be
Hello,
After my & Tom's patch implementing the multi-argument aggregates it seems
that we have fully completed the optional feature T621 of the SQL 2003
standart:
195) Specifications for Feature T621, ?Enhanced numeric functions?:
a) Subclause 6.27, ??:
i) Without Feature T621, ?Enhanced nume
I think there's a call to pgstat_count_index_scan missing in GIN.
Currently, the idx_scan column of pg_stat_*_indexes is stuck at zero
for GIN indexes.
Patch attached.
Thanks,
andreas
Index: src/backend/access/gin/ginscan.c
===
RCS f
Docs and regression tests attached.
One slightly annoying thing is this:
---
regression=# declare foo cursor with hold for VALUES(1,2), (3, 4);
DECLARE CURSOR
regression=# declare foo2 cursor with hold for (VALUES(1,2), (3, 4)) as
foo(i, j);
ERROR: syntax error at or near "as"
LINE 1: ...e foo2
13 matches
Mail list logo
