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 pl
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 more
On Wed, Jul 9, 2014 at 8:42 PM, Marko Tiikkaja 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 chi
On Tue, Jun 24, 2014 at 04:08 AM, 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
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
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 cas
On 05/13/2014 10:45 PM, Rukh Meski wrote:
On Sun, May 11, 2014 at 4: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
On Wed, May 14, 2014 at 8:26 AM, Robert Haas wrote:
> On Sun, May 11, 2014 at 12:47 PM, Tom Lane wrote:
> > Simon Riggs writes:
> >> On 11 May 2014 11:18, Andres Freund wrote:
> >>> I don't know. I'd find UPDATE/DELETE ORDER BY something rather
> >>> useful.
> >
> >> Perhaps if an index exists
On Sun, May 11, 2014 at 12:47 PM, Tom Lane wrote:
> Simon Riggs writes:
>> On 11 May 2014 11:18, Andres Freund 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
On Tue, May 13, 2014 at 8:04 PM, Tom Lane wrote:
> Amit Kapila 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 for new tuple we will now
get tableoi
On Sun, May 11, 2014 at 4: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
Amit Kapila 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)
To make changes to you
On Sun, May 11, 2014 at 10:17 PM, Tom Lane wrote:
> Simon Riggs writes:
>> On 11 May 2014 11:18, Andres Freund 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
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 ch
Simon Riggs writes:
> On 11 May 2014 11:18, Andres Freund 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 question is whether we'd accept an implement
On 11 May 2014 11:18, Andres Freund wrote:
> On 2014-05-11 10:33:10 +0200, Simon Riggs wrote:
>> On 11 May 2014 07:37, Amit Kapila 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:/
On Sun, May 11, 2014 at 10:33 AM, Simon Riggs wrote:
> On 11 May 2014 07:37, Amit Kapila 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
On 2014-05-11 10:33:10 +0200, Simon Riggs wrote:
> On 11 May 2014 07:37, Amit Kapila 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
On 11 May 2014 07:37, Amit Kapila 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 wonderfully articulate way of
On Thu, Mar 13, 2014 at 3:49 AM, Rukh Meski 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 tables.
It just tries
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:
http://www.postgresql.org/mailpref
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.
Hello, Robert.
You wrote:
RH> On Sat, Feb 22, 2014 at 7:02 PM, Rukh Meski 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 r
On Sat, Feb 22, 2014 at 7:02 PM, Rukh Meski 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
> this feature
On Saturday, February 22, 2014 11:57:06 PM, Peter Geoghegan
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 why this is imp
On Sat, Feb 22, 2014 at 3:46 PM, Rukh Meski 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 have documentation
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:
http://www.postgresql.org/ma
27 matches
Mail list logo
