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

Re: DELETE with LIMIT (or my first hack)

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 19:45:39
Message-ID: 1291146339.30414.10.camel@jdavis-ux.asterdata.local (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, 2010-11-30 at 11:12 -0500, Robert Haas wrote:
> > 3. This doesn't work tremendously well for inheritance trees, where
> > ModifyTable acts as sort of an implicit Append node.  You can't just
> > funnel all the tuples through one Sort or Limit node because they aren't
> > all the same rowtype.  (Limit might perhaps not care, but Sort will.)
> > But you can't have a separate Sort/Limit for each table either, because
> > that would give the wrong behavior.  Another problem with funneling all
> > the rows through one Sort/Limit is that ModifyTable did need to know
> > which table each row came from, so it can apply the modify to the right
> > table.
> Could you possibly have ModifyTable -> Limit -> MergeAppend?

Before MergeAppend knows which tuple to produce, it needs to see the
tuples (at least the first one from each of its children), meaning that
it needs to pull them through ModifyTable; and at that point it's
already too late.

Also, assuming LIMIT K, MergeAppend will have N children, meaning N
limits, meaning an effective limit of K*N rather than K.

Can you be a little more specific about what you mean?

	Jeff Davis

In response to


pgsql-hackers by date

Next:From: Marko TiikkajaDate: 2010-11-30 19:47:24
Subject: Re: DELETE with LIMIT (or my first hack)
Previous:From: Peter EisentrautDate: 2010-11-30 19:37:13
Subject: Re: profiling connection overhead

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