On 2010-11-14 8:51 PM +0200, Yeb Havinga wrote:
On 2010-11-14 19:35, Robert Haas wrote:
On Sun, Nov 14, 2010 at 1:01 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
In my opinion, all of these should have the same effect: DELETE all rows
from foo. Any other option means we're going
a pretty bad feature in our hands. Let's not repeat our
mistakes, please.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
RETURNING *)
SELECT 1 FROM t LIMIT 0;
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2010-11-13 5:36 PM +0200, Clark C. Evans wrote:
On Sat, 13 Nov 2010 17:23 +0200, Marko Tiikkaja wrote:
So these queries would behave differently?
WITH t AS (DELETE FROM foo RETURNING *)
SELECT 1 WHERE false;
WITH t AS (DELETE FROM foo RETURNING *)
SELECT 1 FROM t LIMIT 0;
I'm still
Hi all,
It appears that we have a consensus on the behaviour.
I'm going to take some time off this weekend to get a patch with this
behaviour to the next commitfest.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On 2010-11-11 6:41 PM +0200, David Fetter wrote:
On Thu, Nov 11, 2010 at 04:15:34AM +0200, Marko Tiikkaja wrote:
The discussion around wCTE during the last week or so has brought to
my attention that we don't actually have a consensus on how exactly
wCTEs should behave. The question seems
On 11 Nov 2010, at 19:13, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2010-11-11 6:41 PM +0200, David Fetter wrote:
On Thu, Nov 11, 2010 at 04:15:34AM +0200, Marko Tiikkaja wrote:
The discussion around wCTE during the last week or so has brought
of matching it.
Thoughts?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
://archives.postgresql.org/pgsql-hackers/2009-10/msg00566.php ?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to work that way on day zero,
but I am thinking we'd better be able to do it eventually.)
We've discussed this before and the consensus was that as long as we
don't change the results, we can optimize the materialization away.
This seems to be a textbook example of such a case.
Regards,
Marko
, to take one item that the
planner has no access to.
The relevant thread seems to be this one:
http://archives.postgresql.org/pgsql-hackers/2009-11/msg3.php
and I do agree with what you said there.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
an infrastructure for running the executor
separately for every WITH list element when wCTEs are present.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
a bonus. Having to LOCK the target
table makes this feature a lot less useful, even though there are a few
use cases where locking the table would be OK.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
snapshots quite heavily.
I'd also like to see more regression tests for SQL functions, but I'm
going to submit my suggestions as a separate patch.
Regards,
Marko Tiikkaja
*** a/src/backend/catalog/pg_proc.c
--- b/src/backend/catalog/pg_proc.c
***
*** 755,761 fmgr_sql_validator
for every query if the caller doesn't provide a snapshot.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the API of snapmgr.c to make that sane.
*blushes*
Yeah, that makes a lot more sense.
BTW, this patch seems to be also the time to remove the AtStart_Cache()
call in CommandCounterIncrement, as foreseen in the comment there.
Frankly, I have no idea what to do about this.
Regards,
Marko Tiikkaja
places where
pg_parse_and_rewrite is currently used, per comment from Tom.
Regards,
Marko Tiikkaja
*** a/src/backend/catalog/pg_proc.c
--- b/src/backend/catalog/pg_proc.c
***
*** 755,761 fmgr_sql_validator(PG_FUNCTION_ARGS)
--- 755,763
Oid funcoid
,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
with Tom's WITH .. INSERT change. I tweaked the
patch just a bit and it now passes all regression tests so I can review
it. New version attached for documentation purposes.
Regards,
Marko Tiikkaja
*** a/doc/src/sgml/ref/delete.sgml
--- b/doc/src/sgml/ref/delete.sgml
***
*** 21,26
purposes.
Thank you, I didn't notice that commit. In your last patch, the
snippet to add errhint() and ref/insert sgml is unnecessary since it
was for INSERT ... VALUES fix.
The patch seems to work for all cases I can think of.
I'm going to mark this one ready for committer.
Regards,
Marko
of pg_parse_and_rewrite (init_sql_fcache and
fmgr_sql_validator) call check_sql_fn_retval after
pg_parse_and_rewrite so I think we could merge those into the new
function.
Does anyone have any concerns about this? Better ideas?
Regards,
Marko Tiikkaja
*** a/src/backend/catalog/pg_proc.c
that's a bright idea since third
party code might use it, so I suggested adding a new function. Then
again, third party code can't use pg_parse_and_rewrite() any way if/when
the wCTE patch goes in.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
will try to be more clear in the future.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
are
unpredictable.
The patch is also missing a (trivial) change to explain.c.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
' as the first field.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
(-1)
)
INSERT INTO bar (a) WITH RECURSIVE t AS (
SELECT 1
), t AS (
SELECT (-1)
)
VALUES (( SELECT t.?column?
FROM t))
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers
statement would force people to wrap that
INSERT in another CTE.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
of the CTE, not the table foo.
I don't think this is a huge problem in real life, but if someone thinks
otherwise, I think we could just error out if the lists have a different
RECURSIVE definition.
Anyone have a worse example? Thoughts?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing
should
deprecate it in favor of a function which would do the right thing for
SQL functions. Thoughts?
Regards,
Marko Tiikkaja
*** a/src/backend/catalog/pg_proc.c
--- b/src/backend/catalog/pg_proc.c
***
*** 832,838 fmgr_sql_validator(PG_FUNCTION_ARGS
. Annoying for users.
How about using a SAVEPOINT before the cast? Wouldn't fail your
transaction..
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the
representation of the SQL function cache to a list of execution_state
lists, and grab a new snapshot between the lists.
The patch needs a bit more comments and some cleaning up, but I thought
I'd get your input first. Thoughts?
Regards,
Marko Tiikkaja
*** a/src/backend/catalog/pg_proc.c
--- b/src
On 2010-08-31 12:07 AM +0300, I wrote:
I looked at fixing this..
The previous patch had a bug in fmgr_sql() our regression tests didn't
catch. Fixed version attached.
Regards,
Marko Tiikkaja
*** a/src/backend/catalog/pg_proc.c
--- b/src/backend/catalog/pg_proc.c
On 29 Aug 2010, at 13:20, Pavel Stehule pavel.steh...@gmail.com wrote:
Is strange - so slow function can be replaced by plpgsql function and
it's faster
All your SQL language functions were VOLATILE.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers
a MERGE. INSERT fails because
the tuple already exists, but then another transaction, T2, DELETEs that
tuple. T1 tries to UPDATE it, but fails because it doesn't exist
anymore. Not T1 should go back and INSERT the tuple, but that isn't
what happens with this patch, is it?
Regards,
Marko
if that's what
you want, but I don't think doing that automatically would make people
happy.
I don't think having a MERGE that throws UNIQUE violations would make
people happy either.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
with a record-type rather than
multiple columns of non-composite type.),
This isn't entirely accurate, either; the columns are not necessarily of
non-composite types.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
the documentation says?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to SELECT FOR SHARE here for foreign keys to
work, no?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
on doesn't attempt to change the implementation
techniques for foreign keys, because SSI only enforces integrity
among serializable transactions -- and we want foreign keys to be
enforced regardless of the transaction isolation levels used.
Exactly.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers
to be committed separately. Is it
possible to get it in by only adding syntax and little parser/planner
modification, or more executor code?
It's not that simple, see:
http://archives.postgresql.org/pgsql-hackers/2010-02/msg01065.php
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing
in this thread would be left
unaddressed.
I haven't looked at the patch yet (I plan to do so), but +100 for this
feature.
Should we expect a new patch any time soon?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
);
Enforcing that kind of constraints without true serializability seems
impractical.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 8/11/10 1:18 PM +0300, Peter Eisentraut wrote:
On ons, 2010-08-11 at 10:54 +0300, Marko Tiikkaja wrote:
Enforcing that kind of constraints without true serializability seems
impractical.
Yes, but that is being worked on, I understand.
Correct. But you'd have to somehow make
presumably they are not too concerned about
these concurrency issues. Ideally we'd want to do better though.
Yes, you might be right. This feature on its on can greatly simplify
what people now have to do to get triggers on views.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list
provide that).
The problem with the safe way is that it's not safe if called in a
transaction with isolation level set to SERIALIZABLE.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
does PG know
that if the view doesn't have a primary key?
I think these are the main three problems that prevent people from
actually using views, and I think these should be focused on when adding
triggers on VIEWS. I would love to see the feature though.
Any thoughts?
Regards,
Marko
derived values for example.
I see.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
want RETURNING to return
the updated value, as it was when it was deleted.
I'm mainly concerned about concurrently running transactions.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
really matter.
I'm having a hard time imagining that anyone would depend on a behaviour
like this.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
of
the recursive SELECT query with INSERT .. SELECT, UPDATE .. FROM or
DELETE .. USING. Cyclic dependencies are out of the scope of this
patch; I'm not planning on adding any new features to regular CTEs.
[1] http://git.postgresql.org/gitweb?p=users/johto/postgres.git;a=summary
Regards,
Marko
change the patch accordingly.
For what it's worth, I think replication_mode is a lot clearer.
Acknowledge_commit sounds like it would do something similar to
asynchronous_commit.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
be
preferable for EXPLAIN ANALYZE, but I don't see why this is. Maybe we
should wait until we hear from Tom?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 7/23/2010 8:52 PM, David Fetter wrote:
On Thu, Jul 22, 2010 at 08:43:35PM +0300, Marko Tiikkaja wrote:
Did I misunderstand the code? And if I didn't, why do we do this
differently?
You mentioned in IRC that this was in aid of getting wCTEs going. How
are these things connected
On 7/23/2010 10:00 PM, Robert Haas wrote:
On Fri, Jul 23, 2010 at 2:13 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
Currently, I'm trying to make wCTEs behave a bit like RULEs do. But if
every rewrite product takes a new snapshot, wCTEs will behave very
unpredictably.
But because
in the regular execution scenario it does.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 7/23/2010 10:46 PM, Andres Freund wrote:
On Fri, Jul 23, 2010 at 03:30:03PM -0400, Robert Haas wrote:
On Fri, Jul 23, 2010 at 3:19 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
This may be a bit hard to follow, but essentially what happens is that in
EXPLAIN ANALYZE, the INSERT
to put a lot of effort into making
this work with our current partitioning method when the partitioning
patches are just around the corner. The developer time should be
directed at those patches instead.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On 7/24/10 12:37 AM +0300, Alvaro Herrera wrote:
Excerpts from Marko Tiikkaja's message of vie jul 23 14:13:18 -0400 2010:
On 7/23/2010 8:52 PM, David Fetter wrote:
On Thu, Jul 22, 2010 at 08:43:35PM +0300, Marko Tiikkaja wrote:
Did I misunderstand the code? And if I didn't, why do we do
by this; UPDATE and DELETE can take a look at
the new tuple but that's completely separate from the snapshot.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the executor separately for all of them.
Is a wCTE going to be expanded into multiple queries?
If not, it sounds like we're all agreed.
Yes, it will have to be. I tried to make it work for 9.0 by not
expanding, and it didn't work out too well.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers
On 7/24/10 1:20 AM +0300, Alvaro Herrera wrote:
It seems like it's EXPLAIN ANALYZE that needs fixing.
Yeah, looks like it. I see SQL functions also take a new snapshot for
every query.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
? And if I didn't, why do we do this
differently?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
it.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
be
to unconditionally force the tuplestores to disk, but that sounds painful.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
any obvious flaws in this?
Any feedback is welcome. I'd also be happy to get some help on this
project.
Regards,
Marko Tiikkaja
*** a/src/backend/commands/copy.c
--- b/src/backend/commands/copy.c
***
*** 1092,1098 DoCopy(const CopyStmt *stmt, const char *queryString
On 7/12/10 9:07 PM +0300, I wrote:
Consider:
WITH t AS (SELECT 1),
t2 AS (SELECT * FROM t2)
VALUES (true);
That should of course have been SELECT * FROM t, not t2.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
queries into a list of Queries and store that
list into the CommonTableExprs. The planner would then use this
information and also expand the rewrite products.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
to do it.
As far as I recall, at least 99% of the user requests for this type
of behavior, maybe 100%, would be satisfied by recognizing the
group-by-primary-key case. So I think we should do that and be happy.
+1
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers
that.
Having said that, I also think that supporting in exclusion
constraints would be useful. I can't come up with a real-world use case
right now though.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
:
CREATE UNIQUE INDEX a_single_row ON a ((1));
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
;
DELETE 1
TXB = select a from foo for share; -- waits
What am I missing?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Zeilen)
T2 DELETE FROM a WHERE i = 1; -- Nope, so delete a with i = 1 (this
blocks, because T1 is still holding the lock).
Obviously you wouldn't delete anything with a SHARE lock.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
suggestion in a more general way,
suggesting the use of row-level locks. T2 should be holding an
exclusive row-level lock (SELECT ... FOR UPDATE) when checking for
references.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
the rows in a serializable
transaction so this doesn't solve the problem.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
better, but I can't
think of anything.
Thoughts?
Regards,
Marko Tiikkaja
*** a/src/backend/parser/analyze.c
--- b/src/backend/parser/analyze.c
***
*** 730,742 transformInsertRow(ParseState *pstate, List *exprlist
On 2010-03-29 11:19 +0200, Pavel Stehule wrote:
postgres=# explain select a from a left join b on true;
This is effectively a cross join and it would give wrong answers. Try
SELECT a FROM a LEFT JOIN b ON a.a = b.b;
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql
.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
of the syntax
optional is just breaking that portability. We already have a
non-portable, non-standard syntax.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
: (b = 2)
Total runtime: 0.075 ms
(3 rows)
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.. USING on that CTE.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, 11 Feb 2010 10:53:22 -0500, Robert Haas robertmh...@gmail.com
wrote:
On Thu, Feb 11, 2010 at 8:46 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
On 2010-02-11 03:44 +0200, I wrote:
I'm going to have to disappoint a bunch of people and give up. :-(
Btw. would it make sense
On Thu, 11 Feb 2010 19:28:28 +0200, I wrote:
On Thu, 11 Feb 2010 10:53:22 -0500, Robert Haas robertmh...@gmail.com
wrote:
On Thu, Feb 11, 2010 at 8:46 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
On 2010-02-11 03:44 +0200, I wrote:
I'm going to have to disappoint a bunch of people
On 2010-02-10 03:20 +0200, Tom Lane wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2010-02-10 02:19 +0200, Tom Lane wrote:
You still haven't explained why it's a good idea to change the snapshot
after the executor has started. Right at the moment I'm prepared to
reject
On 2010-02-10 21:59 +0200, Robert Haas wrote:
On Wed, Feb 10, 2010 at 5:05 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
On 2010-02-10 03:20 +0200, Tom Lane wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2010-02-10 02:19 +0200, Tom Lane wrote:
You still haven't
.
I'm looking at this, but I can't think of any good way of associating
the tuplestores from PortalRunMulti() with the correct CTEs. Any ideas?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On 2010-02-11 00:50 +0200, Marko Tiikkaja wrote:
On 2010-02-10 23:57 +0200, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
If the executor has buried in it the assumption that the snapshot
can't change after startup, then does that mean that we need to start
up and shut down
On 2010-02-11 01:58 +0200, Robert Haas wrote:
On Wed, Feb 10, 2010 at 6:25 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
On 2010-02-11 00:50 +0200, Marko Tiikkaja wrote:
Ok, what about the following:
- after planning the original query, standard_planner() goes through
the list
that there
would've been a shot, even if I finished the patch on time.
Thanks everyone for helping out and reviewing this, especially Robert
and Tom.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On 2010-02-08 18:42 +0200, Robert Haas wrote:
On Thu, Feb 4, 2010 at 11:57 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
Here's an updated patch. Only changes from the previous patch are
fixing the above issue and a regression test for it.
- I'm not sure that canSetTag
whenever the scan nodes need to reinit.
Does this sound completely unacceptable?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2010-02-10 02:19 +0200, Tom Lane wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
Does this sound completely unacceptable?
You still haven't explained why it's a good idea to change the snapshot
after the executor has started. Right at the moment I'm prepared to
reject
On 2010-02-08 18:42 +0200, Robert Haas wrote:
On Thu, Feb 4, 2010 at 11:57 AM, Marko Tiikkaja
Here's an updated patch. Only changes from the previous patch are
fixing the above issue and a regression test for it.
- I'm not sure that canSetTag is the right name for the additional
argument
asking: is there a simple enough way around this? Would
updating scan-rs_nblocks before scanning the first tuple be OK?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
On 2010-02-09 01:09 +0200, Tom Lane wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
I traced this down to heapam.c, which has this:
...
This doesn't exactly work anymore since we modify the snapshot after
calling ExecInitScan().
So don't do that. The executor is generally
could turn them into some
documentation? David?
The documentation has definitely improved from the last time Robert
looked at it, but I fear it still needs some more work. I'm willing to
do that work, but I need something concrete.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list
. Is there one somewhere?
While working on the docs, I noticed one problem with the patch itself:
it doesn't handle multi-statement DO INSTEAD rules correctly. I'm going
to submit a fix for that later.
Any suggestions, whatsoever, are welcome.
Regards,
Marko Tiikkaja
*** a/doc/src/sgml
On 2010-02-05 07:14 UTC+2, Takahiro Itagaki wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi wrote:
Here's an updated patch. Only changes from the previous patch are
fixing the above issue and a regression test for it.
* In the regression tests, almost all of them don't have ORDER
501 - 600 of 655 matches
Mail list logo
