On 2014-06-24 11:08, Heikki Linnakangas wrote:
IMHO this needs to work with inheritance if we are to accept it. It
would be a rather strange limitation for no apparent reason, other than
that we didn't bother to implement it. It doesn't seem very difficult in
theory to add the table OID to the
On 7/10/14 5:44 AM, Amit Kapila wrote:
Basically, I wanted to say that apart from modified columns, we just
need to pass table OID. If I am reading correctly, the same is
mentioned by Heikki as well.
Yes, Heikki was talking about that approach. I was more interested in
the significantly
Hi Amit,
On 5/14/14 6:41 AM, Amit Kapila wrote:
IIUC, the way new design will work is that for new tuple we will now
get tableoid+TID, modified column values as an input (for inheritance
tables we will get this for all child tables as well) for ModifyTable
and get old tuple (which in current
On 5/11/14 6:47 PM, Tom Lane wrote:
The $64 question is whether we'd accept an implementation that fails
if the target table has children (ie, is partitioned). That seems
to me to not be up to the project's usual quality expectations, but
maybe if there's enough demand for a partial solution we
On Tue, Jun 24, 2014 at 04:08 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
IMHO this needs to work with inheritance if we are to accept it. It would be
a rather strange limitation for no apparent reason, other than that we
didn't bother to implement it. It doesn't seem very difficult
On Wed, Jul 9, 2014 at 8:42 PM, Marko Tiikkaja ma...@joh.to wrote:
Hi Amit,
On 5/14/14 6:41 AM, Amit Kapila wrote:
IIUC, the way new design will work is that for new tuple we will now
get tableoid+TID, modified column values as an input (for inheritance
tables we will get this for all
On 05/13/2014 10:45 PM, Rukh Meski wrote:
On Sun, May 11, 2014 at 4:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The $64 question is whether we'd accept an implementation that fails
if the target table has children (ie, is partitioned). That seems
to me to not be up to the project's usual quality
On Wed, May 14, 2014 at 8:26 AM, Robert Haas robertmh...@gmail.com wrote:
On Sun, May 11, 2014 at 12:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 11 May 2014 11:18, Andres Freund and...@2ndquadrant.com wrote:
I don't know. I'd find UPDATE/DELETE
On Sun, May 11, 2014 at 12:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 11 May 2014 11:18, Andres Freund and...@2ndquadrant.com wrote:
I don't know. I'd find UPDATE/DELETE ORDER BY something rather
useful.
Perhaps if an index exists to provide an
On Sun, May 11, 2014 at 10:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 11 May 2014 11:18, Andres Freund and...@2ndquadrant.com wrote:
I don't know. I'd find UPDATE/DELETE ORDER BY something rather
useful.
Perhaps if an index exists to provide an
Amit Kapila amit.kapil...@gmail.com writes:
How about sorting step, are you thinking to have MergeAppend
node for it beneath ModifyTable?
Well yeah, that's pretty much the point.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On Sun, May 11, 2014 at 4:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The $64 question is whether we'd accept an implementation that fails
if the target table has children (ie, is partitioned). That seems
to me to not be up to the project's usual quality expectations, but
maybe if there's
On Tue, May 13, 2014 at 8:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Amit Kapila amit.kapil...@gmail.com writes:
How about sorting step, are you thinking to have MergeAppend
node for it beneath ModifyTable?
Well yeah, that's pretty much the point.
IIUC, the way new design will work is that
On 11 May 2014 07:37, Amit Kapila amit.kapil...@gmail.com wrote:
Tom Lane has explained these problems in a very clear manner
in his below mail and shared his opinion about this feature as
well.
http://www.postgresql.org/message-id/26819.1291133...@sss.pgh.pa.us
I don't have Tom's
On 2014-05-11 10:33:10 +0200, Simon Riggs wrote:
On 11 May 2014 07:37, Amit Kapila amit.kapil...@gmail.com wrote:
Tom Lane has explained these problems in a very clear manner
in his below mail and shared his opinion about this feature as
well.
On Sun, May 11, 2014 at 10:33 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 11 May 2014 07:37, Amit Kapila amit.kapil...@gmail.com wrote:
Tom Lane has explained these problems in a very clear manner
in his below mail and shared his opinion about this feature as
well.
On 11 May 2014 11:18, Andres Freund and...@2ndquadrant.com wrote:
On 2014-05-11 10:33:10 +0200, Simon Riggs wrote:
On 11 May 2014 07:37, Amit Kapila amit.kapil...@gmail.com wrote:
Tom Lane has explained these problems in a very clear manner
in his below mail and shared his opinion about
Simon Riggs si...@2ndquadrant.com writes:
On 11 May 2014 11:18, Andres Freund and...@2ndquadrant.com wrote:
I don't know. I'd find UPDATE/DELETE ORDER BY something rather
useful.
Perhaps if an index exists to provide an ordering that makes it clear
what this means, then yes.
The $64
On 2014-05-11 12:47:21 -0400, Tom Lane wrote:
Another idea is that the main reason we do things like this is the
assumption that for UPDATE, ModifyTable receives complete new rows
that only need to be pushed back into the table (and hence have
to already match the rowtype of the specific child
On Thu, Mar 13, 2014 at 3:49 AM, Rukh Meski rukh.me...@yahoo.ca wrote:
Oops. Of course shouldn't try and change how INSERT works. Latest version
attached.
I had given a brief look into this patch and found that the
implementation for Update .. ORDER BY is not appropriate for
inheritance
Hi,
Here's an updated patch. I had to push the LIMIT processing into ModifyTable
to make the behaviour sane in parallel scenarios. As usual, please ignore if
you're busy with 9.4. I will work on better docs and more tests from now on
and am preparing to make a solid case for adding this.
Oops. Of course shouldn't try and change how INSERT works. Latest version
attached.
♜
update_delete_order_by_limit_v2.diff
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Hello, Robert.
You wrote:
RH On Sat, Feb 22, 2014 at 7:02 PM, Rukh Meski rukh.me...@yahoo.ca wrote:
Sorry, I wanted to minimize the attention my message attracts. I mostly
posted it to let people know I plan on working on this for 9.5 to avoid
duplicated effort. I will post more
On Sat, Feb 22, 2014 at 7:02 PM, Rukh Meski rukh.me...@yahoo.ca wrote:
Sorry, I wanted to minimize the attention my message attracts. I mostly
posted it to let people know I plan on working on this for 9.5 to avoid
duplicated effort. I will post more documentation and my reasons for wanting
Hello hackers,
I know you're busy wrapping up the 9.4 release, so please ignore this patch.
♜
update_delete_order_by_limit_v0.diff
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Sat, Feb 22, 2014 at 3:46 PM, Rukh Meski rukh.me...@yahoo.ca wrote:
I know you're busy wrapping up the 9.4 release, so please ignore this patch.
I think you should describe what the patch does, why you believe the
feature is necessary, and perhaps how it compares to other, similar
things. You
On Saturday, February 22, 2014 11:57:06 PM, Peter Geoghegan p...@heroku.com
wrote:
I think you should describe what the patch does, why you believe the
feature is necessary, and perhaps how it compares to other, similar
things. You have documentation changes here, but that doesn't really
tell us
27 matches
Mail list logo
