Re: contsel and gist - Mailing list pgsql-hackers

From Ben
Subject Re: contsel and gist
Date
Msg-id 3BA3D995-4597-4C25-BB38-B0FB4E53189B@gmail.com
Whole thread Raw
In response to Re: contsel and gist  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: contsel and gist
List pgsql-hackers
thanks for the prompt reply.

On Oct 28, 2010, at 10:50 AM, Tom Lane wrote:

>> 1 - am i wrong in my assessment?  is the constant contsel, areasel, etc hurting us?
>
> The stub selectivity functions definitely suck.

i'm taking this as implying that my intuition here is basically right.

>> 2 - how hard would it be to implement contsel et al for period data types?
>
> If it were easy, it'd likely have been done already :-(

i am interested in learning more about this, in hopes that it might be possible for me to do it some day.  do you have
anypointers as far as things to look at to learn from?  i imagine this must be a problem for the postgis people
too.....

i guess the first step is to figure out what kind of statistics / histograms to collect for the period datatype.  (i
don'tsee anything in pg_stats.)  has there been previous work / thinking on this? 

> However, having said that: the constant value of the stub contsel
> function is intended to be small enough to encourage use of an
> indexscan.  Maybe we just need to decrease it a bit more.  Have you
> investigated what the cutover point is for your queries?

i'd be happy to investigate this for you, but my guess is my dataset is probably not a good example to use for setting
theconstant more generally.  i'm joining an 8e10 table vs a 150K table, so the selectivity fraction would probably have
todrop by many orders of magnitude.  that being said, i'll poke around and see if i can find the cutoff point.  is
therean easy way to do this that doesn't involve recompiling postgres? 

best regards, b

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: plperl arginfo
Next
From: Peter Eisentraut
Date:
Subject: Re: psql autocompletion for \z and \dg