On Monday 10 December 2007 20:01, Erik Jones wrote:
> 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?
>
One way is to set a static bin id for each partition, then do a select
Vivek Khera <[EMAIL PROTECTED]> writes:
> I, along with at least Erik, was thinking that the constraint
> expression would be evaluated to determine whether to include the
> partition in the final plan. Based on Tom's description, it is not
> the case: the planner basically proves that the c
On Dec 11, 2007, at 10:44 AM, Gregory Stark wrote:
The problem Tom's tried to explain is that the function may or may not
preserve the bin. So for example if you wanted to bin based on the
final digit
of a numeric number, so you had a constraint like
I, along with at least Erik, was thinki
On Dec 11, 2007, at 10:08 AM, Erik Jones wrote:
b.) precomputing the bin and directly accessing the child table will
be the only options we have for now.
This is where I'm headed I have only one or two queries that don't
specify the partitioned ID, and those need a full table scan anyh
On Dec 11, 2007, at 9:44 AM, Gregory Stark wrote:
"Erik Jones" <[EMAIL PROTECTED]> writes:
Well, given that the bin is computed as a function of some_id,
the most
natural way would be to not have to mention that bin in SELECT
statements at
all.
The problem Tom's tried to explain is th
"Erik Jones" <[EMAIL PROTECTED]> writes:
> Well, given that the bin is computed as a function of some_id, the most
> natural way would be to not have to mention that bin in SELECT statements at
> all.
The problem Tom's tried to explain is that the function may or may not
preserve the bin. So
>
> Well, given that the bin is computed as a function of some_id, the
> most natural way would be to not have to mention that bin in SELECT
> statements at all. However, it does appear that either a.) including
> the bin as a table attribute and in the where clause (either directly
> or the compu
On Dec 11, 2007, at 7:20 AM, Mike Rylander wrote:
On Dec 10, 2007 8:01 PM, Erik Jones <[EMAIL PROTECTED]> 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?
A
On Dec 10, 2007 8:01 PM, Erik Jones <[EMAIL PROTECTED]> 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 %, perha
On Mon, 2007-12-10 at 23:18 -0500, Tom Lane wrote:
> Erik Jones <[EMAIL PROTECTED]> writes:
> If you dig in the PG archives you will find some discussions of
> inventing a "real equality" flag for operators, which would authorize
> the planner to make such deductions for any immutable operator/fun
"Trevor Talbot" <[EMAIL PROTECTED]> writes:
> Erik is questioning is why it has to assume anything. Why can't it
> just execute the expression and find out?
Because the whole point of the problem is to *not* execute the
expression, but to assume that it must yield false, for every row
of a given p
On 12/10/07, Trevor Talbot <[EMAIL PROTECTED]> wrote:
> On 12/10/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Erik Jones <[EMAIL PROTECTED]> writes:
> > > I guess what I don't understand is that given the query
> >
> > > SELECT COUNT(*)
> > > FROM table
> > > WHERE some_id=34;
> >
> > > on a table w
On 12/10/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> Erik Jones <[EMAIL PROTECTED]> writes:
> > I guess what I don't understand is that given the query
>
> > SELECT COUNT(*)
> > FROM table
> > WHERE some_id=34;
>
> > on a table with the much discussed constraint (34 % 100) = 32 isn't
> > simply evalu
Erik Jones <[EMAIL PROTECTED]> writes:
> I guess what I don't understand is that given the query
> SELECT COUNT(*)
> FROM table
> WHERE some_id=34;
> on a table with the much discussed constraint (34 % 100) = 32 isn't
> simply evaluated as a one-time filter whenever whatever constraint
> excl
On Dec 10, 2007, at 5:50 PM, Tom Lane wrote:
Erik Jones <[EMAIL PROTECTED]> writes:
Forgive me if I'm nagging on this, I just want to understand this
better. Why does evaluating a CHECK constraint like 'CHECK some_id %
100 = 32' against WHERE clause like 'WHERE some_id=1132' need to know
anyt
Erik Jones <[EMAIL PROTECTED]> writes:
> Forgive me if I'm nagging on this, I just want to understand this
> better. Why does evaluating a CHECK constraint like 'CHECK some_id %
> 100 = 32' against WHERE clause like 'WHERE some_id=1132' need to know
> anything about equality properites of %?
On Dec 10, 2007, at 4:29 PM, Tom Lane wrote:
Erik Jones <[EMAIL PROTECTED]> writes:
You beat me to the punch on this one. I was wanting to use modulo
operations for bin style partitioning as well, but this makes things
pretty awkward as well as unintuitive. So, to the postgres gurus:
What ar
Erik Jones <[EMAIL PROTECTED]> writes:
> You beat me to the punch on this one. I was wanting to use modulo
> operations for bin style partitioning as well, but this makes things
> pretty awkward as well as unintuitive. So, to the postgres gurus:
> What are the limitations of check constra
On Dec 10, 2007, at 1:21 PM, Erik Jones wrote:
You beat me to the punch on this one. I was wanting to use modulo
operations for bin style partitioning as well, but this makes things
pretty awkward as well as unintuitive. So, to the postgres gurus:
What are the limitations of check cons
On Dec 7, 2007, at 10:51 PM, Mason Hale wrote:
I'm implementing table partitioning on 8.2.5 -- I've got the tables
set up to partition based on the % 10 value of a key.
My problem is that I can't get the planner to take advantage of the
partitioning without also adding a key % 10 to the wh
I'm implementing table partitioning on 8.2.5 -- I've got the tables set up
to partition based on the % 10 value of a key.
My problem is that I can't get the planner to take advantage of the
partitioning without also adding a key % 10 to the where clause.
Is there any way around that?
My child tabl
21 matches
Mail list logo
