From: | "Mike Rylander" <mrylander(at)gmail(dot)com> |
---|---|
To: | "Erik Jones" <erik(at)myemma(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: partitioned table query question |
Date: | 2007-12-11 13:20:38 |
Message-ID: | b918cf3d0712110520p5e8d28a4pd0c774c13d7c5e0f@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Dec 10, 2007 8:01 PM, Erik Jones <erik(at)myemma(dot)com> 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
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2007-12-11 13:27:25 | Re: comparing rows |
Previous Message | Gregory Stark | 2007-12-11 12:41:10 | Re: partitioned table query question |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2007-12-11 13:46:16 | Re: [HACKERS] BUG #3799: csvlog skips some logs |
Previous Message | Bruce Momjian | 2007-12-11 13:18:42 | Re: Document how to turn off disk write cache on popular operating |