From: | Alex Pilosov <alex(at)pilosoft(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] inet << indexability |
Date: | 2001-06-16 18:49:04 |
Message-ID: | Pine.BSO.4.10.10106161444060.17529-100000@spider.pilosoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 16 Jun 2001, Tom Lane wrote:
> Alex Pilosov <alex(at)pilosoft(dot)com> writes:
> > Also, I have a question: I put in a regression test to check that the type
> > can be indexed, by doing 'explain select ...'. However, the expected
> > result may vary when the optimizer is tweaked.
>
> Yes, I'd noted that already in looking at your prior version. I think
> it's best not to do an EXPLAIN in the regress test, because I don't want
> to have to touch the tests every time the cost functions are tweaked.
I'll remove it with resubmitted patch.
> However, we can certainly check to make sure that the results of an
> indexscan are what we expect. Is the table set up so that this is a
> useful test case? For example, it'd be nice to check boundary
> conditions (eg, try both << and <<= on a case where they should give
> different results).
I'll do that too.
> Do you have any thought of making network_scan_first and
> network_scan_last user-visible functions? (Offhand I see no use for
> them to a user, but maybe you do.) If not, I'd suggest not using the
> fmgr call protocol for them, but just making them pass and return inet*,
> or possibly Datum. No need for the extra notational cruft of
> DirectFunctionCall.
I didn't want to make them user-visible, however, the alternative, IMHO,
is worse, since these functions rely on network_broadcast and
network_network to do the work, calling sequence would be:
a) indxpath casts Datum to inet, passes to network_scan*
b) network_scan will create new Datum, pass it to network_broadcast
c) network_scan will extract inet from Datum returned
d) indxpath will then cast inet back to Datum :)
Which, I think, is pretty messy :)
> Another minor stylistic gripe is that you should use bool/true/false
> where appropriate, not int/1/0. Otherwise it looks pretty good.
I'll clean it up and resubmit.
> Oh, one more thing: those dynloader/openbsd.h and psql/tab-complete.c
> changes don't belong in this patch...
Sorry, my fault
-alex
From | Date | Subject | |
---|---|---|---|
Next Message | Manuel Sugawara | 2001-06-16 19:09:47 | Re: postgres dies while doing vacuum analyze |
Previous Message | Tom Lane | 2001-06-16 18:43:28 | Re: [PATCH] inet << indexability |