Neil Conway <[EMAIL PROTECTED]> writes:
> Keep in mind that it would be conceivable to ship an 8.0.x release which
> replaces ARC with another algorithm. That would be a somewhat
> non-trivial change, but there's no reason we need to wait for a major
> release (i.e. 8.1 or 8.2) to replace ARC.
It's not that we couldn't fold a non-ARC algorithm into the 8.0.x
release series, it's that it'd be a fairly fundamental change in
some critical code. Critical from both the reliability and performance
standpoints. I would be comfortable with developing a replacement
algorithm as part of the 8.1 development cycle, and then considering
a back-patch after 8.1 is out and has shown that it's not completely
broken. But to replace it with less testing than that would be
irresponsible, at least by the standards we have customarily used for
minor releases.
This is assuming that we conclude we need a whole new algorithm to
dodge the patent. Another line of attack should be to see whether we
can make minor tweaks to avoid it. I'm pessimistic about that, but
it deserves some amount of investigation before we go down the wholesale
replacement path.
We already had been considering a short development cycle for 8.1, and
I think that this issue will set that decision in stone. What I'm
currently thinking about is a couple of months development and the same
for beta, which would allow a release in June or so. I have already
suggested to core that we should insist on 8.1 not requiring an initdb,
so as to ensure that people will migrate up to it easily from 8.0.
Aside from the ARC issue, we have already one significant Windows
porting issue (%$n in message strings) and I'm sure we will find more
once 8.0 is out and getting some real use. I would expect us to focus
on fixing issues of that caliber and probably being pretty stingy on
new features.
(Of course, if we do take this approach, it's questionable whether we'd
need to bother with a back-patch.)
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
