Re: [PERFORM] partition queries hitting all partitions even though check key is specified

2010-07-12 Thread Joshua D. Drake
On Mon, 2010-07-12 at 22:01 -0500, Josh Berkus wrote: > On 9/2/09 10:05 AM, Kevin Kempter wrote: > > On Wednesday 02 September 2009 09:02:27 Scott Marlowe wrote: > >> On Wed, Sep 2, 2009 at 8:52 AM, Kevin Kempter > > wrote: > >>> Hi all; > >>> > >>> I cant figure out why we're scanning all of our

Re: [PERFORM] partition queries hitting all partitions even though check key is specified

2010-07-12 Thread Josh Berkus
On 9/2/09 10:05 AM, Kevin Kempter wrote: > On Wednesday 02 September 2009 09:02:27 Scott Marlowe wrote: >> On Wed, Sep 2, 2009 at 8:52 AM, Kevin Kempter > wrote: >>> Hi all; >>> >>> I cant figure out why we're scanning all of our partitions. I don't think extract() is immutable, which would prett

Re: [PERFORM] partition queries hitting all partitions even though check key is specified

2009-09-02 Thread Scott Carey
On 9/2/09 8:59 AM, "Joshua D. Drake" wrote: > On Wed, 2009-09-02 at 09:39 -0600, Kevin Kempter wrote: > >>> >>> You sure you remembered those fiddly little casts everywhere? >>> (Frankly, declaring "time" as integer and not timestamp here strikes >>> me as utter lunacy.) What PG version are

Re: [PERFORM] partition queries hitting all partitions even though check key is specified

2009-09-02 Thread Tom Lane
Kevin Kempter writes: > In any case I ran the exact same query as you and it still scans most (but > not > all) partitions. AFAICT it's scanning the right partitions in this example. What's different in the case where it scans all? > Were on version This seems to have got truncated ...

Re: [PERFORM] partition queries hitting all partitions even though check key is specified

2009-09-02 Thread Tom Lane
"Joshua D. Drake" writes: > As far as I know constraint exclusion doesn't work with date_part or > extract(). Uh, you clipped the example in my message showing that it does, at least in the particular case Kevin showed us. There are some variants of date_part that aren't immutable, but timestamp

Re: [PERFORM] partition queries hitting all partitions even though check key is specified

2009-09-02 Thread Joshua D. Drake
On Wed, 2009-09-02 at 09:39 -0600, Kevin Kempter wrote: > > > > You sure you remembered those fiddly little casts everywhere? > > (Frankly, declaring "time" as integer and not timestamp here strikes > > me as utter lunacy.) What PG version are you using? > > > > regards, tom l

Re: [PERFORM] partition queries hitting all partitions even though check key is specified

2009-09-02 Thread Kevin Kempter
On Wednesday 02 September 2009 09:19:20 Tom Lane wrote: > Kevin Kempter writes: > > I cant figure out why we're scanning all of our partitions. > > The example works as expected for me: > > regression=# CREATE TABLE url_hits ( > id integer NOT NULL, > content_type_id integer, > file_ex

Re: [PERFORM] partition queries hitting all partitions even though check key is specified

2009-09-02 Thread Tom Lane
Kevin Kempter writes: > I cant figure out why we're scanning all of our partitions. The example works as expected for me: regression=# CREATE TABLE url_hits ( id integer NOT NULL, content_type_id integer, file_extension_id integer, "time" integer, bytes integer NOT NULL,

Re: [PERFORM] partition queries hitting all partitions even though check key is specified

2009-09-02 Thread Greg Jaman
Check the caveats at http://www.postgresql.org/docs/current/static/ddl-partitioning.html "Constraint exclusion only works when the query's WHERE clause contains constants. A parameterized query will not be optimized, since the planner cannot know which partitions the parameter value might select a

Re: [PERFORM] partition queries hitting all partitions even though check key is specified

2009-09-02 Thread bricklen
On Wed, Sep 2, 2009 at 8:05 AM, Kevin Kempter wrote: > > > > the explain plan shows most any query scans/hits all partitions even if > > > we specify the partition key: > > > > > > explain select * from pwreport.url_hits where "time" > > > > date_part('epoch'::text, '2009-08-12'::timestamp without

Re: [PERFORM] partition queries hitting all partitions even though check key is specified

2009-09-02 Thread Kevin Kempter
On Wednesday 02 September 2009 08:55:38 Kenneth Marshall wrote: > The planner does not yet work as efficiently as it could > with child tables. Check the recent mail archives for a > long discussion of the same. > > Regards, > Ken > > On Wed, Sep 02, 2009 at 08:52:30AM -0600, Kevin Kempter wrote: >

Re: [PERFORM] partition queries hitting all partitions even though check key is specified

2009-09-02 Thread Kevin Kempter
On Wednesday 02 September 2009 09:02:27 Scott Marlowe wrote: > On Wed, Sep 2, 2009 at 8:52 AM, Kevin Kempter wrote: > > Hi all; > > > > I cant figure out why we're scanning all of our partitions. > > > > We setup our tables like this: > > > > > > Base Table: > > > > CREATE TABLE url_hits ( > >

Re: [PERFORM] partition queries hitting all partitions even though check key is specified

2009-09-02 Thread Scott Marlowe
On Wed, Sep 2, 2009 at 8:52 AM, Kevin Kempter wrote: > Hi all; > > I cant figure out why we're scanning all of our partitions. > > We setup our tables like this: > > > Base Table: > > CREATE TABLE url_hits ( >    id integer NOT NULL, >    content_type_id integer, >    file_extension_id integer, >  

Re: [PERFORM] partition queries hitting all partitions even though check key is specified

2009-09-02 Thread Kenneth Marshall
The planner does not yet work as efficiently as it could with child tables. Check the recent mail archives for a long discussion of the same. Regards, Ken On Wed, Sep 02, 2009 at 08:52:30AM -0600, Kevin Kempter wrote: > Hi all; > > I cant figure out why we're scanning all of our partitions. > >

[PERFORM] partition queries hitting all partitions even though check key is specified

2009-09-02 Thread Kevin Kempter
Hi all; I cant figure out why we're scanning all of our partitions. We setup our tables like this: Base Table: CREATE TABLE url_hits ( id integer NOT NULL, content_type_id integer, file_extension_id integer, "time" integer, bytes integer NOT NULL, path_id integer, p