Re: Hash partitioning.

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Hash partitioning.
Дата
Msg-id 20130625162159.GD18297@momjian.us
обсуждение исходный текст
Ответ на Re: Hash partitioning.  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Jun 25, 2013 at 12:08:34PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > I looked at predtest.c but I can't see how we accept >= and <= ranges,
> > but not CHECK (a % 16 == 3).  It is the '%' operator?  I am not sure why
> > the hashme() function is there.  Wouldn't it work if hashme() was an
> > immutable function?
> 
> No.  Robert's description is exactly correct: it's a question of whether
> we can know that the semantics of function X have anything to do with
> the behavior of operator Y.  In the case of something like CHECK (X >= 16)
> combined with WHERE X = 10, if the given = and >= operators belong to
> the same btree opclass family then we can assume that their semantics
> are compatible and then apply reasoning to show that these two clauses
> can't both be true for the same value of X.  We can *not* use "X = 10"
> to reason about the behavior of anything that isn't in the = operator's
> btree opclass, because we don't assume that "=" means "absolutely
> identical for every purpose".  And in fact it does not mean that for
> several pretty common datatypes (float being another example besides
> numeric).

OK, so it is really the index comparisons that we are using;  makes
sense.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [PATCH] add long options to pgbench (submission 1)
Следующее
От: Robert Haas
Дата:
Сообщение: Re: pluggable compression support