Re: Planning a change of representation in the planner - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Planning a change of representation in the planner
Date
Msg-id 1044605336.5672.2.camel@taru.tm.ee
Whole thread Raw
In response to Planning a change of representation in the planner  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Planning a change of representation in the planner
List pgsql-hackers
Tom Lane kirjutas R, 07.02.2003 kell 06:35:
> I've been thinking of doing this for a while just on efficiency grounds,
> but kept putting it off because I don't expect much of any performance
> gain on simple queries.  (You need a dozen or so tables in a query
> before the inefficiencies of the list representation really start to
> hurt.)  But tonight I'm thinking I'll do it anyway, because it'll also
> be impervious to duplicate-element bugs.
> 
> Comments?

Maybe the quicker way to avoid duplicate-element bugs (and get faster
merges) is to keep the lists ordered, so instead of just appending the
next int, you scan to the proper place and put it there (if it is not
there already).

Ordered lists are also much faster ( just O(N) )  to
compare/union/intersect.

-- 
Hannu Krosing <hannu@tm.ee>


pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Status report: regex replacement
Next
From: Teodor Sigaev
Date:
Subject: Please apply patch