Re: Hash partitioning.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Yuri Levinsky <yuril(at)celltick(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Hash partitioning.
Date: 2013-06-25 16:08:34
Message-ID: 11325.1372176514@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <bruce(at)momjian(dot)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).

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yuri Levinsky 2013-06-25 16:08:46 Re: Hash partitioning.
Previous Message Robert Haas 2013-06-25 16:07:54 Re: refresh materialized view concurrently