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 kgri...@ymail.com wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp wrote:
(2014/08/15 6:18), Rukh Meski wrote:
Based on the feedback on my previous patch, I've
(2014/09/17 1:58), Robert Haas wrote:
On Tue, Sep 16, 2014 at 11:31 AM, Kevin Grittner kgri...@ymail.com wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp 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
(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
Etsuro Fujita fujita.ets...@lab.ntt.co.jp 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
On Tue, Sep 16, 2014 at 11:31 AM, Kevin Grittner kgri...@ymail.com wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp 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
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
(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
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
(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 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
On 09/03/2014 06:39 PM, Robert Haas wrote:
On Wed, Sep 3, 2014 at 11:02 AM, Marko Tiikkaja ma...@joh.to 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
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
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
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, it
On Tue, Sep 9, 2014 at 2:57 AM, Heikki Linnakangas hlinnakan...@vmware.com
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
(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
On Mon, Sep 1, 2014 at 8:06 AM, Marko Tiikkaja ma...@joh.to 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.
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
On Wed, Sep 3, 2014 at 11:02 AM, Marko Tiikkaja ma...@joh.to 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
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
(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
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
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
Marko Tiikkaja ma...@joh.to 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
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.
On Mon, Aug 25, 2014 at 12:18 PM, Etsuro Fujita fujita.ets...@lab.ntt.co.jp
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 fujita.ets...@lab.ntt.co.jp 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
On Sun, Aug 24, 2014 at 11:48 PM, Etsuro Fujita fujita.ets...@lab.ntt.co.jp
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
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
