> -Original Message-
> From: Ben [mailto:midfi...@gmail.com]
> Sent: Friday, October 29, 2010 12:16 PM
> To: Igor Neyman
> Cc: pgsql-performance@postgresql.org
> Subject: Re: partitioning question 1
>
> On Oct 29, 2010, at 7:38 AM, Igor Neyman wrote:
>
> >> is my intuition completely
On Oct 29, 2010, at 7:38 AM, Igor Neyman wrote:
>> is my intuition completely off on this?
>>
>> best regards, ben
>>
>
> If your SELECT retrieves substantial amount of records, table scan could
> be more efficient than index access.
>
> Now, if while retrieving large amount of records "WHERE
> -Original Message-
> From: Ben [mailto:midfi...@gmail.com]
> Sent: Thursday, October 28, 2010 12:37 PM
> To: pgsql-performance@postgresql.org
> Subject: partitioning question 1
>
> hello --
>
> my last email was apparently too long to respond to so i'll
> split it up into shorter piec
whoops, didn't see the i=9 (linebreak! linebreak!)
nonetheless that is a static constant constraint on the column i, and i was
asking if constraint exclusions would work for dynamic constraints (like those
derived from a table joined against.) so for example the bar table has only
0-9 in its h
On Thu, 2010-10-28 at 12:59 -0700, Ben wrote:
> On Oct 28, 2010, at 12:44 PM, Joshua D. Drake wrote:
> >
> > My tests show you are incorrect:
> >
> >
> > part_test=# explain analyze select * from foo join bar using (i) where
> > i=9;
> >QUERY
>
On Thu, 2010-10-28 at 12:59 -0700, Ben wrote:
> explain analyze select * from foo join bar using (i);
vs
explain analyze select * from foo join bar using (i) where i=9;
On Oct 28, 2010, at 12:44 PM, Joshua D. Drake wrote:
>
> My tests show you are incorrect:
>
>
> part_test=# explain analyze select * from foo join bar using (i) where
> i=9;
>QUERY
> PLAN
> -
On Thu, 2010-10-28 at 12:25 -0700, Ben wrote:
> i think we are talking about two different things here: the constraints on
> the table, and the where-clause constraints in a query which may or may not
> trigger constraint exclusion. i understand that table constraints have to be
> constants --
On Oct 28, 2010, at 11:50 AM, Joshua D. Drake wrote:
>>> Yes the constraints have to be static. Not sure about the operator
>>> question honestly.
>>
>> this seems to severely restrict their usefulness -- our queries are data
>> warehouse analytical -type queries, so the constraints are usually
On Thu, 2010-10-28 at 11:44 -0700, Ben wrote:
> > Yes the constraints have to be static. Not sure about the operator
> > question honestly.
>
> this seems to severely restrict their usefulness -- our queries are data
> warehouse analytical -type queries, so the constraints are usually
> data-d
thanks for the prompt response. some comments / questions below :
On Oct 28, 2010, at 10:31 AM, Joshua D. Drake wrote:
>> ...constraint exclusion is able to eliminate table partitions. the I/O
>> advantages of having queries target small subtables are the same as the I/O
>> advantages of clust
On Thu, 2010-10-28 at 09:36 -0700, Ben wrote:
> hello --
>
> my last email was apparently too long to respond to so i'll split it up into
> shorter pieces. my first question :
>
> my understanding of how range partitioning and constraint exclusion works
> leads me to believe that it does not b
hello --
my last email was apparently too long to respond to so i'll split it up into
shorter pieces. my first question :
my understanding of how range partitioning and constraint exclusion works leads
me to believe that it does not buy any query performance that a clustered index
doesn't alr
13 matches
Mail list logo
