Neil Conway <[EMAIL PROTECTED]> writes: > On Mon, 2003-11-03 at 10:04, Tom Lane wrote: >> You have effectively reverted the code to its previous slow state.
> Erm, the original version of this code in CVS (from ~7 years ago) is the > following: Hm. I coulda sworn that at some point I changed that code from essentially-what-you're-proposing to the current state. Memory is misserving me I guess. > I don't understand: granted, this applies equal() to each element of the > list, but why would that be particularly slow? The point is that the elements of the lists could be large, complicated structures that will take noticeable amounts of time to compare. A typical case would be that the elements are targetlist structures, with a minimum of three contained nodes each with several fields. equal() on that will take much longer than just counting the presence of the list element. I will grant that there are situations where your proposed change would be a win --- in particular, for long lists wherein the first few elements differ, it'd be faster to do it as you suggest. But Postgres mostly deals with relatively short lists, in which situation the compare-the-lengths step is quite cheap and can save a fair amount of per-node comparison processing. So I don't think it'd be a win overall to change. FYI, equali() (now in list.c) used to look pretty nearly like the code in equal(), but now looks exactly as you propose for equal(). The difference is that in equali(), we know for certain that comparing two list members is a very cheap operation. In equal() it's likely to be nontrivial. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]