On Dec 10, 2007 8:01 PM, Erik Jones <erik@xxxxxxxxxx> wrote:
>
[snip]
> Again, though, is there some better way to go about implementing some
> kind of hash based partitioning in postgres besides this that would
> be more natural wrt queries?
>
Adding a column to hold the result of the %, perhaps updated by a
trigger so your app needn't change, and partitioning on that would be
the obvious way to get what you want today. If you have a byte or two
of slack space in the tuple (by alignment), just use a "char" or an
INT2. Assuming you don't affect fully aligned base tuple size, there
should be no table bloat, and no noticeable effect on speed. As far
as being more natural WRT queries, well, you'd add to your where
clause
bin = 34
instead of
some_id % 100 = 34
The former seems to me to be more natural from the narrow perspective
of the SELECT statement.
--miker
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
