Re: [HACKERS] optimizer and type question

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: riedel+(at)CMU(dot)EDU, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] optimizer and type question
Date: 1999-03-23 17:09:52
Message-ID: 24471.922208992@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Clark Evans 1999-03-23 22:58:03 Re: [HACKERS] Re: Developers Globe (FINAL)
Previous Message Dan Gowin 1999-03-23 17:04:50 RE: [HACKERS] Re: postmaster dies (was Re: Very disappointing pe rformance)