Tom Lane wrote:
> Steve Wampler <swampler@noao.edu> writes:
>
>>We've got an older system in production (PG 7.2.4). Recently
>>one of the users has wanted to implement a selective delete,
>>but is finding that the time it appears to take exceeds her
>>patience factor by several orders of magnitude. Here's
>>a synopsis of her report. It appears that the "WHERE
>>id IN ..." is resulting in a seq scan that is causing
>>the problem, but we're not SQL expert enough to know
>>what to do about it.
>
>
>>Can someone point out what we're doing wrong, or how we
>>could get a (much) faster delete? Thanks!
>
>
> Update to 7.4 or later ;-)
I was afraid you'd say that :-) I'm not officially involved in
this project anymore and was hoping for a fix that wouldn't drag
me back in. The security issues aren't a concern because this
DB is *well* hidden from the outside world (it's part of a telescope
control system behind several firewalls with no outside access).
However, the data-loss-grade bugs issue *is* important. We'll
try to do the upgrade as soon as we get some cloudy days to
actually do it!
Is the performance behavior that we're experiencing a known
problem with 7.2 that has been addressed in 7.4? Or will the
upgrade fix other problems while leaving this one?
> Quite seriously, if you're still using 7.2.4 for production purposes
> you could justifiably be accused of negligence. There are three or four
> data-loss-grade bugs fixed in the later 7.2.x releases, not to mention
> security holes; and that was before we abandoned support for 7.2.
> You *really* need to be thinking about an update.
Thanks!
Steve
--
Steve Wampler -- swampler@noao.edu
The gods that smiled on your birth are now laughing out loud.
