Skip site navigation (1) Skip section navigation (2)

Re: equal() perf tweak

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: equal() perf tweak
Date: 2003-11-03 15:04:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Neil Conway <neilc(at)samurai(dot)com> writes:
> This code is inefficient, however: length() requires iterating through
> the entire list, so this code scans both lists twice. The attached patch
> improves this by implementing equal() with a single scan of both lists.

You have effectively reverted the code to its previous slow state.

The problem with what you've done is that it recursively applies equal()
to the list contents, which may take a very large number of cycles, only
to eventually fail because one list is a prefix of the other.  The point
of the current coding is to detect that condition before we recurse.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: StephenDate: 2003-11-03 15:04:52
Subject: Re: Experimental patch for inter-page delay in VACUUM
Previous:From: Tom LaneDate: 2003-11-03 15:01:55
Subject: Re: adding support for posix_fadvise()

pgsql-patches by date

Next:From: Neil ConwayDate: 2003-11-03 16:47:55
Subject: Re: equal() perf tweak
Previous:From: Tom LaneDate: 2003-11-03 15:00:25
Subject: Re: bufmgr code cleanup

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group