On 09/24/2014 05:22 AM, Etsuro Fujita wrote:
(2014/09/17 1:58), Robert Haas wrote:
On Tue, Sep 16, 2014 at 11:31 AM, Kevin Grittner wrote:
Etsuro Fujita wrote:
(2014/08/15 6:18), Rukh Meski wrote:
Based on the feedback on my previous patch, I've separated only the
LIMIT part into its own fe
(2014/09/17 1:58), Robert Haas wrote:
On Tue, Sep 16, 2014 at 11:31 AM, Kevin Grittner wrote:
Etsuro Fujita wrote:
(2014/08/15 6:18), Rukh Meski wrote:
Based on the feedback on my previous patch, I've separated only the
LIMIT part into its own feature. This version plays nicely with
inherit
On Tue, Sep 16, 2014 at 11:31 AM, Kevin Grittner wrote:
> Etsuro Fujita wrote:
>> (2014/08/15 6:18), Rukh Meski wrote:
>>> Based on the feedback on my previous patch, I've separated only the
>>> LIMIT part into its own feature. This version plays nicely with
>>> inheritance. The intended use is
Etsuro Fujita wrote:
> (2014/08/15 6:18), Rukh Meski wrote:
>> Based on the feedback on my previous patch, I've separated only the
>> LIMIT part into its own feature. This version plays nicely with
>> inheritance. The intended use is splitting up big UPDATEs and DELETEs
>> into batches more eas
(2014/08/15 6:18), Rukh Meski wrote:
Based on the feedback on my previous patch, I've separated only the
LIMIT part into its own feature. This version plays nicely with
inheritance. The intended use is splitting up big UPDATEs and DELETEs
into batches more easily and efficiently.
IIUC, the pa
On 9/10/14 12:05 PM, Etsuro Fujita wrote:
(2014/09/10 18:33), Marko Tiikkaja wrote:
You can already change *this patch* to do ModifyTable <- Limit <-
LockRows. If we think that's what we want, we should rewrite this patch
right now.
I think it might be relatively easy to do that for single-ta
(2014/09/10 18:33), Marko Tiikkaja wrote:
On 9/10/14 11:25 AM, Etsuro Fujita wrote:
The reason is because I think that after implementing #2, we should
re-implement this feature by extending the planner to produce a plan
tree such as ModifyTable+Limit+Append, maybe with LockRows below the
Limit
On 9/10/14 11:25 AM, Etsuro Fujita wrote:
The reason is because I think that after implementing #2, we should
re-implement this feature by extending the planner to produce a plan
tree such as ModifyTable+Limit+Append, maybe with LockRows below the
Limit node. Such an approach would prevent dupli
(2014/09/10 16:57), Marko Tiikkaja wrote:
On 2014-09-10 04:25, Etsuro Fujita wrote:
(2014/09/09 18:57), Heikki Linnakangas wrote:
What's not clear to me is whether it make sense to do 1) without 2) ? Is
UPDATE .. LIMIT without support for an ORDER BY useful enough? And if we
apply this patch no
On 2014-09-10 04:25, Etsuro Fujita wrote:
(2014/09/09 18:57), Heikki Linnakangas wrote:
What's not clear to me is whether it make sense to do 1) without 2) ? Is
UPDATE .. LIMIT without support for an ORDER BY useful enough? And if we
apply this patch now, how much of it needs to be rewritten aft
(2014/09/09 18:57), Heikki Linnakangas wrote:
On 09/03/2014 06:39 PM, Robert Haas wrote:
Now some people might argue that we have that anyway, but the fact is
that a lot of people are using inheritance today, even with all its
flaws, and they wouldn't be if there were a long laundry list of
limi
On Tue, Sep 9, 2014 at 2:57 AM, Heikki Linnakangas
wrote:
> I agree. If we are to support UPDATE .. ORDER BY .. LIMIT, it should work
> with inheritance. So the path forward is (using Marko's phrasing upthread):
>
>1) We put the LIMIT inside ModifyTable like this patch does. This
> doesn't
On 09/09/2014 01:46 PM, Marko Tiikkaja wrote:
On 9/9/14 12:37 PM, I wrote:
And no, these are not routine things so keep your "use
partitions" suggestions to yourselves.
My apologies. This was not directed at you personally, Heikki, and in
any case it was unnecessarily hostile.
No worries, i
On 9/9/14 12:37 PM, I wrote:
And no, these are not routine things so keep your "use
partitions" suggestions to yourselves.
My apologies. This was not directed at you personally, Heikki, and in
any case it was unnecessarily hostile.
.marko
--
Sent via pgsql-hackers mailing list (pgsql-hac
On 9/9/14 11:57 AM, Heikki Linnakangas wrote:
What's not clear to me is whether it make sense to do 1) without 2) ? Is
UPDATE .. LIMIT without support for an ORDER BY useful enough?
I'd say so; I could use it right now. I have to remove millions of
lines from a table, but I don't want the liv
On 09/03/2014 06:39 PM, Robert Haas wrote:
On Wed, Sep 3, 2014 at 11:02 AM, Marko Tiikkaja wrote:
On 9/3/14 4:46 PM, Robert Haas wrote:
Making it
suck more because you don't think it's as important as your feature
is, in my opinion, not cool.
I really can't see how that would make inheritanc
On Wed, Sep 3, 2014 at 11:02 AM, Marko Tiikkaja wrote:
> On 9/3/14 4:46 PM, Robert Haas wrote:
>> Making it
>> suck more because you don't think it's as important as your feature
>> is, in my opinion, not cool.
>
> I really can't see how that would make inheritance suck *more*. You can't
> do UPD
On 9/3/14 4:46 PM, Robert Haas wrote:
Making it
suck more because you don't think it's as important as your feature
is, in my opinion, not cool.
I really can't see how that would make inheritance suck *more*. You
can't do UPDATE .. ORDER BY now, and you wouldn't be able to do it after
the pa
On Mon, Sep 1, 2014 at 8:06 AM, Marko Tiikkaja wrote:
> Ideally? Yeah, that would be great. But I don't see anyone volunteering to
> do that work, and I think holding back a useful feature (ORDER BY with
> UPDATE/DELETE) in hopes of getting someone to volunteer to do it is insane.
> Now, you're
On 8/29/14 4:33 PM, Tom Lane wrote:
So either it has to be inside
ModifyTable or the ModifyTable has to somehow pass something to a Limit
node on top of it
... or we add a LockRows node below the Limit node. Yeah, that would make
UPDATE/LIMIT a tad slower, but I think that might be preferable
Marko Tiikkaja writes:
> The LIMIT part *has* to happen after the rows have been locked or it
> will work very surprisingly under concurrency (sort of like how FOR
> SHARE / FOR UPDATE worked before 9.0).
Good point.
> So either it has to be inside
> ModifyTable or the ModifyTable has to some
On 8/29/14 1:53 PM, I wrote:
This is just my personal opinion, but what I think should happen is:
1) We put the LIMIT inside ModifyTable like this patch does. This
doesn't prevent us from doing ORDER BY in the future, but helps numerous
people who today have to
Oops, looks like I didn't f
On 8/29/14 12:20 PM, Etsuro Fujita wrote:
The patch places limit-counting inside ModifyTable, and works well for
inheritance trees, but I'm not sure that that is the right way to go. I
think that this feature should be implemented in the way that we can
naturally extend it to the ORDER-BY-LIMIT
(2014/08/25 15:48), Etsuro Fujita wrote:
(2014/08/15 6:18), Rukh Meski wrote:
Based on the feedback on my previous patch, I've separated only the
LIMIT part into its own feature. This version plays nicely with
inheritance. The intended use is splitting up big UPDATEs and DELETEs
into batches m
On Sun, Aug 24, 2014 at 11:48 PM, Etsuro Fujita wrote:
> Hi Rukh,
>
>
> (2014/08/15 6:18), Rukh Meski wrote:
>
>> Based on the feedback on my previous patch, I've separated only the
>> LIMIT part into its own feature. This version plays nicely with
>> inheritance. The intended use is splitting
Etsuro Fujita wrote:
> (2014/08/15 6:18), Rukh Meski wrote:
>> Based on the feedback on my previous patch, I've separated only the
>> LIMIT part into its own feature. This version plays nicely with
>> inheritance. The intended use is splitting up big UPDATEs and DELETEs
>> into batches more easi
On Mon, Aug 25, 2014 at 12:18 PM, Etsuro Fujita
wrote:
> (2014/08/15 6:18), Rukh Meski wrote:
>>
>> Based on the feedback on my previous patch, I've separated only the
>> LIMIT part into its own feature. This version plays nicely with
>> inheritance. The intended use is splitting up big UPDATEs
Hi Rukh,
(2014/08/15 6:18), Rukh Meski wrote:
Based on the feedback on my previous patch, I've separated only the
LIMIT part into its own feature. This version plays nicely with
inheritance. The intended use is splitting up big UPDATEs and DELETEs
into batches more easily and efficiently.
Be
Greetings,
Based on the feedback on my previous patch, I've separated only the
LIMIT part into its own feature. This version plays nicely with
inheritance. The intended use is splitting up big UPDATEs and DELETEs
into batches more easily and efficiently.
♜
*** a/doc/src/sgml/ref/delete.sgml
--
29 matches
Mail list logo