Re: [HACKERS] optimizer and type question - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] optimizer and type question
Date
Msg-id 24471.922208992@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] optimizer and type question  (Bruce Momjian <maillist@candle.pha.pa.us>)
Responses longer-term optimizer musings
List pgsql-hackers
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> What we really need is some way to determine how far the requested value
> is from the min/max values.  With int, we just do (val-min)/(max-min). 
> That works, but how do we do that for types that don't support division.
> Strings come to mind in this case.

What I'm envisioning is that we still apply the (val-min)/(max-min)
logic, but apply it to numeric values that are produced in a
type-dependent way.

For ints and floats the conversion is trivial, of course.

For strings, the first thing that comes to mind is to return 0 for a
null string and the value of the first byte for a non-null string.
This would give you one-part-in-256 selectivity which is plenty good
enough for what the selectivity code needs to do.  (Actually, it's
only that good if the strings' first bytes are pretty well spread out.
If you have a table containing English words, for example, you might
only get about one part in 26 this way, since the first bytes will
probably only run from A to Z.  Might be better to use the first two
characters of the string to compute the selectivity representation.)

In general, you can apply this logic as long as you can come up with
some numerical approximation to the data type's sorting order.  It
doesn't have to be exact.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] optimizer and type question
Next
From: Clark Evans
Date:
Subject: Re: [HACKERS] Re: Developers Globe (FINAL)