Skip site navigation (1) Skip section navigation (2)

Re: DELETE with LIMIT (or my first hack)

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Daniel Loureiro <loureirorg(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: DELETE with LIMIT (or my first hack)
Date: 2010-11-30 15:41:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Nov 30, 2010 at 10:04 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Nov 29, 2010 at 11:25 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>>> I can't say I'd be excited by this feature. In quite a few years of writing
>>> SQL I don't recall ever wanting such a gadget.
>> It's something I've wanted periodically, though not badly enough to do
>> the work to make it happen.
> It would certainly look like nothing but a crude hack if the feature is
> only available for DELETE and not UPDATE.

I'm not sure this is true, given Andrew's comment that the bulk
deletion argument is the only one he finds compelling, but I'd surely
be in favor of supporting both.

> Unfortunately, the UPDATE
> case would be an order of magnitude harder (think inheritance trees
> where the children aren't all alike).

I don't understand why there's anything more to this than sticking a
Limit node either immediately above or immediately below the
ModifyTable node.

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2010-11-30 15:43:47
Subject: Re: crash-safe visibility map, take three
Previous:From: Tom LaneDate: 2010-11-30 15:38:02
Subject: Re: crash-safe visibility map, take three

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group