Good point. One question: are we happy calling this a 'VALUES list'? It's
better than a 'table value constructor'. I took the lead from a comment in
the
source.
table value constructor is name from ANSI. All people wiil find t.v.c., not
values list. I vote table value constructor.
Regar
On Aug 4, 2006, at 9:42 , Gavin Sherry wrote:
... with update? I associate it very closely with INSERT. After all,
INSERT is the only statement where we've had VALUES as part of the
grammar.
Of course! Thanks for catching the glitch. I must have a bad RAM chip.
Michael Glaesemann
grzm seespo
On Thu, 3 Aug 2006, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > Docs and regression tests attached.
>
> I've applied the regression tests (with a few additions), but I'm
> feeling dissatisfied with this approach to documenting VALUES.
> It seems to be mostly missing the point ab
On Aug 3, 2006, at 23:58 , Tom Lane wrote:
Should we give VALUES its own reference page? That doesn't quite
seem helpful either.
I think we should go for a separate reference page, as VALUES appears
to be expanding quite a bit. Up till now I've thought of VALUES only
in conjunction with
Gavin Sherry <[EMAIL PROTECTED]> writes:
> Docs and regression tests attached.
I've applied the regression tests (with a few additions), but I'm
feeling dissatisfied with this approach to documenting VALUES.
It seems to be mostly missing the point about VALUES being usable
whereever SELECT is. I'
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
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
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
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 <[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:
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:
> 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:
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
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
Joe Conway wrote:
Tom Lane wrote:
Here's what I've got so far. I think there's probably more gold to be
mined in terms of reducing runtime memory consumption (I don't like the
list_free_deep bit, we should use a context), but functionally it seems
complete.
I checked out memory usage, and it
Anyway, with the attached diff, the 2 million inserts case is back to
about 730 MB memory use, and speed is pretty much the same as reported
yesterday (i.e both memory use and performance better than mysql with
innodb tables).
That's all that matters ;)
Joshua D. Drake
--
=== The Postg
Tom Lane wrote:
Here's what I've got so far. I think there's probably more gold to be
mined in terms of reducing runtime memory consumption (I don't like the
list_free_deep bit, we should use a context), but functionally it seems
complete.
I checked out memory usage, and it had regressed to ab
Gavin Sherry <[EMAIL PROTECTED]> writes:
> Is this intentional:
> template1=# values(1), (2);
> column1
> -
>1
>2
> (2 rows)
You bet. VALUES is parallel to SELECT in the SQL grammar, so AFAICS
it should be legal anywhere you can write SELECT.
The basic productions in th
Tom Lane wrote:
Here's what I've got so far. I think there's probably more gold to be
mined in terms of reducing runtime memory consumption (I don't like the
list_free_deep bit, we should use a context), but functionally it seems
complete. I'm off to dinner again, it's in your court to look ove
On Tue, 1 Aug 2006, Joe Conway wrote:
> Gavin Sherry wrote:
> > Is this intentional:
> >
> > template1=# values(1), (2);
> > column1
> > -
> >1
> >2
> > (2 rows)
> >
> > This is legal because of:
> >
> > simple_select:
> > /* ... */
> > | values_clause
Gavin Sherry wrote:
Is this intentional:
template1=# values(1), (2);
column1
-
1
2
(2 rows)
This is legal because of:
simple_select:
/* ... */
| values_clause { $$ = $2; }
hmm, not sure about that...
Also, I am working out
Tom Lane wrote:
Here's what I've got so far. I think there's probably more gold to be
mined in terms of reducing runtime memory consumption (I don't like the
list_free_deep bit, we should use a context), but functionally it seems
complete. I'm off to dinner again, it's in your court to look ove
Tom,
Is this intentional:
template1=# values(1), (2);
column1
-
1
2
(2 rows)
This is legal because of:
simple_select:
/* ... */
| values_clause { $$ = $2; }
Also, I am working out some docs and regression tests.
Gavin
--
Here's what I've got so far. I think there's probably more gold to be
mined in terms of reducing runtime memory consumption (I don't like the
list_free_deep bit, we should use a context), but functionally it seems
complete. I'm off to dinner again, it's in your court to look over some
more if you
Tom Lane wrote:
ISTM that this should be represented using an RTE_SUBQUERY node in the
outer query; the alias attaches to that node, not to the VALUES itself.
So I don't think you need that alias field in the jointree entry either.
If we stick with the plan of representing VALUES as if it were S
Joe Conway <[EMAIL PROTECTED]> writes:
> Good feedback -- thanks! But without the RTE, how would VALUES in the
> FROM clause work?
Is it different from INSERT? I'm just imagining a Values node in
the jointree and nothing in the rangetable.
If I'm reading the spec correctly, VALUES is exactly pa
Tom Lane wrote:
There are basically two ways you could go about this:
1. Make a new jointree leaf node type to represent a VALUES construct,
and dangle the list of lists of expressions off that.
2. Make a new RangeTblEntry type to represent a VALUES construct, and
just put a RangeTblRef to it i
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> There are basically two ways you could go about this:
>> 1. Make a new jointree leaf node type to represent a VALUES construct,
>> and dangle the list of lists of expressions off that.
>> 2. Make a new RangeTblEntry type to represent a VAL
Joe Conway wrote:
Since the feature freeze is only about a week off, I wanted to post this
patch even though it is not yet ready to be applied.
Sorry -- I just realized that two new files for ValuesScan didn't make
it into the patch posted earlier. Here they are now -- please untar in
your
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
I'm liking this too. But when you say "jointree node", are you saying to
model the new node type after NestLoop/MergeJoin/HashJoin nodes? These
are referred to as "join nodes" in ExecInitNode. Or as you mentioned a
couple of times, should
30 matches
Mail list logo
