Re: equal() perf tweak

Neil Conway <neilc(at)samurai(dot)com> 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