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
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
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
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 ...
"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
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
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
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,
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
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
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:
>
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 (
> >
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,
>
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.
>
>
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
15 matches
Mail list logo