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
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
Joe Conway <[EMAIL PROTECTED]> writes:
> In case you can make use of it, here's my latest. I found that I was
> being too aggressive at freeing the input nodes to transformExpr() in
> transformRangeValues() after using them. In many cases the returned node
> is a new palloc'd node, but in some c
Joshua,> So now it's MySQL users' turn to say, "Sure, but speed isn't
> everything" :-)"Sure, but speed isn't everything... We can accept 02/31/2006 as a validdate. Let's see PostgreSQL do that!"I got the joke :)But: it is still a problem when converting. As accepting 2006-02-31 as a valid date
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
I wanted to post an updated patch even though there are still things not
working again after conversion to bare expressions.
I've been through the planner part of this and it looks OK (one or two
small errors). I'm currently messing with
Joe Conway <[EMAIL PROTECTED]> writes:
> I wanted to post an updated patch even though there are still things not
> working again after conversion to bare expressions.
I've been through the planner part of this and it looks OK (one or two
small errors). I'm currently messing with a revised versi
Michael Fuhr wrote:
On Mon, Jul 31, 2006 at 04:19:43PM -0400, Alvaro Herrera wrote:
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
The good news is that from a memory and perfomance standpoint, my simple
test now shows us outperforming mysql:
Sweet ;-)
I love this team. Kudos!
So
On Mon, Jul 31, 2006 at 04:19:43PM -0400, Alvaro Herrera wrote:
> Tom Lane wrote:
> > Joe Conway <[EMAIL PROTECTED]> writes:
> > > The good news is that from a memory and perfomance standpoint, my simple
> > > test now shows us outperforming mysql:
> >
> > Sweet ;-)
>
> I love this team. Kudos!
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > The good news is that from a memory and perfomance standpoint, my simple
> > test now shows us outperforming mysql:
>
> Sweet ;-)
I love this team. Kudos!
--
Alvaro Herrerahttp://www.CommandPrompt.com
Joe Conway <[EMAIL PROTECTED]> writes:
> The good news is that from a memory and perfomance standpoint, my simple
> test now shows us outperforming mysql:
Sweet ;-)
I'm up to my *ss in fixing relation locking, but will get back to your
thing as soon as that's done. I think you're close enough t
Tom Lane wrote:
As far as avoiding overhead goes, here's what I'm thinking:
* The Values RTE node should contain a list of lists of bare
expressions, without TargetEntry decoration (you probably do not
need ResTarget in the raw parse tree for VALUES, either).
* The ValuesScan plan node will jus
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
I'm afraid though that after 2 or so days heading down the last path you
suggested (namely making a new jointree leaf node) I was having trouble,
and at the same time came to the conclusion that adding a new RTE was
alot cleaner and made
Joe Conway <[EMAIL PROTECTED]> writes:
>> I'm afraid though that after 2 or so days heading down the last path you
>> suggested (namely making a new jointree leaf node) I was having trouble,
>> and at the same time came to the conclusion that adding a new RTE was
>> alot cleaner and made more se
Joe Conway wrote:
Tom Lane wrote:
I thought Joe was off in a corner doing a whole new version.
(I'm willing to help if he needs help...)
Yeah, I was going to post the latest tonight.
Sorry for the delay. Ever see the movie "The Money Pit"? This afternoon
I started to think I lived in that h
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Are you going to apply this? Seems it is ready.
I thought Joe was off in a corner doing a whole new version.
(I'm willing to help if he needs help...)
Yeah, I was going to post the latest tonight.
I'm afraid though that after 2 or
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Are you going to apply this? Seems it is ready.
>
> I thought Joe was off in a corner doing a whole new version.
> (I'm willing to help if he needs help...)
OK, just checking.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDB
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Are you going to apply this? Seems it is ready.
I thought Joe was off in a corner doing a whole new version.
(I'm willing to help if he needs help...)
regards, tom lane
---(end of broadcast)-
Are you going to apply this? Seems it is ready.
---
Joe Conway wrote:
> Tom Lane wrote:
> > Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> >
> >>Strange. Last time I checked I thought MySQL dump used 'multivalue
>
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
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
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
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
Strange. Last time I checked I thought MySQL dump used 'multivalue
lists in inserts' for dumps, for the same reason that we use COPY
I think Andrew identified the critical point upthread: they don't try
to put an unlimited n
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Strange. Last time I checked I thought MySQL dump used 'multivalue
> lists in inserts' for dumps, for the same reason that we use COPY
I think Andrew identified the critical point upthread: they don't try
to put an unlimited number of rows in
I did some experimentation just now, and could not get mysql to accept a
command longer than about 1 million bytes. It complains about
Got a packet bigger than 'max_allowed_packet' bytes
which seems a bit odd because max_allowed_packet is allegedly set to
16 million, but anyway I don't think p
I did some experimentation just now, and could not get mysql to accept a
command longer than about 1 million bytes. It complains about
Got a packet bigger than 'max_allowed_packet' bytes
which seems a bit odd because max_allowed_packet is allegedly set to
16 million, but anyway I don't think p
Chris Browne wrote:
[EMAIL PROTECTED] (Christopher Kings-Lynne) writes:
The major downside is that somewhere between 9000 and 1
VALUES-targetlists produces "ERROR: stack depth limit
exceeded". Perhaps for the typical use-case this is sufficient
though.
I'm open to better ideas, comments
[EMAIL PROTECTED] (Christopher Kings-Lynne) writes:
>> The major downside is that somewhere between 9000 and 1
>> VALUES-targetlists produces "ERROR: stack depth limit
>> exceeded". Perhaps for the typical use-case this is sufficient
>> though.
>> I'm open to better ideas, comments, objections
>> If the use case is people running MySQL dumps, then there will be
>> millions of values-targetlists in MySQL dumps.
I did some experimentation just now, and could not get mysql to accept a
command longer than about 1 million bytes. It complains about
Got a packet bigger than 'max_all
Christopher Kings-Lynne wrote:
The major downside is that somewhere between 9000 and 1
VALUES-targetlists produces "ERROR: stack depth limit exceeded".
Perhaps for the typical use-case this is sufficient though.
I'm open to better ideas, comments, objections...
If the use case is peop
Andrew Dunstan wrote:
Christopher Kings-Lynne wrote:
The major downside is that somewhere between 9000 and 1
VALUES-targetlists produces "ERROR: stack depth limit exceeded".
Perhaps for the typical use-case this is sufficient though.
I'm open to better ideas, comments, objections...
I
The major downside is that somewhere between 9000 and 1
VALUES-targetlists produces "ERROR: stack depth limit exceeded".
Perhaps for the typical use-case this is sufficient though.
I'm open to better ideas, comments, objections...
If the use case is people running MySQL dumps, then there
Joe Conway wrote:
. multiple values clauses for INSERT
The best way might be to fabricate a selectStmt equiv to
"SELECT UNION ALL SELECT ...",
but that still feels like a hack.
Here is a patch pursuant to my earlier post. It has the advantage of
being fairly simple and noninvasive.
The
32 matches
Mail list logo
