Re: SP-GiST support for inet datatypes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SP-GiST support for inet datatypes
Date
Msg-id 12344.1471824042@sss.pgh.pa.us
Whole thread Raw
In response to Re: SP-GiST support for inet datatypes  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: SP-GiST support for inet datatypes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>  Tom> I started to look at this patch.  The reported speedup is pretty
>  Tom> nice, but ...

> The builtin gist support for inet seems quite surprisingly slow; ip4r
> beats it into the ground without difficulty. (I'd be curious how well
> this sp-gist version stacks up against ip4r.)

Yeah ... what I find interesting about this patch is that the opclass's
data splitting rules don't seem all that much different from what the
existing gist opclass knows how to do.  I suspect that the speed
differential arises because the gist opclass's penalty and picksplit
algorithms are somehow extremely stupid, which hints that maybe they
could be made better.  In particular, IIRC the test cases that we looked
at when making the gist opclass tended to have only one or a few netmask
lengths, whereas in this data set the netmasks are all over the place.
I theorize that that's what's breaking the gist algorithm.  Not sure
exactly how to make it better though.

This example also seems to be showing up some lack of intelligence in
SPGiST itself, in that there are an awful lot of pages with a lot of
empty space on them.  Not sure why.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: dsm_unpin_segment
Next
From: Michael Paquier
Date:
Subject: Re: standalone backend PANICs during recovery