From: | Csaba Nagy <nagy(at)ecircle-ag(dot)com> |
---|---|
To: | chris smith <dmagick(at)gmail(dot)com> |
Cc: | Postgres general mailing list <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: allow LIMIT in UPDATE and DELETE |
Date: | 2006-05-19 13:26:37 |
Message-ID: | 1148045197.17461.377.camel@coppola.muc.ecircle.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> That would spare a HashAggregate and an index scan. The index scan would
> very likely not be a problem, as the same index entries are visited in
> the subquery and likely are cached, and the HashAggregate should be also
> fast for the max 1000 rows it has to handle, but they are still
> completely unnecessary for my purpose, so I still think the LIMIT on
> DELETE and UPDATE would make perfect sense.
Oh, it just occured to me: the subquery is using a different index than
the outer loop, so we can forget about caching. Considering that the
outer loop uses an index 10x bigger than the subquery, and that means
~50million entries, and the typical situation where this would be used
mostly selects 1000 rows indeed, the LIMIT on DELETE for this case would
mean for sure ~ 50% speedup.
Cheers,
Csaba.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-05-19 13:51:03 | Re: allow LIMIT in UPDATE and DELETE |
Previous Message | Csaba Nagy | 2006-05-19 13:21:01 | Re: allow LIMIT in UPDATE and DELETE |