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
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 cases
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 the spec's
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
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 to
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/
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 now it's
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
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 version
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 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
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 sense to
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
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
lists in
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
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
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
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 this
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
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
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
[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
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,
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
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
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 into
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
Joe Conway wrote:
. multiple values clauses for INSERT
The best way might be to fabricate a selectStmt equiv to
SELECT targetlist UNION ALL SELECT targetlist...,
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
28 matches
Mail list logo
