In response to Vratislav Benes :
> but when I try make a condition by join table, the query plan is not optimal:
>
>
> select period_id from periods where y=2009 and w=14;
> period_id
> ---
>704
> (1 row)
>
>
> explain select sum(s_pcs),sum(s_val)
> from data d inner join perio
Grzegorz Jaśkiewicz writes:
> Learn it to not generate with "WITH IN (subq)", is this can be quite
> slow on postgresql. Use joins instead.
OK, I've split the query in two (can't make Django to generate JOIN in this
case) and it always uses index now. This immediately opened road for
other optim
Hello,
could you help me with joined query from partitioned table, please? I
have a table "data" with partitions by period_id
CREATE TABLE data
(
period_id smallint NOT NULL DEFAULT 0,
store_id smallint NOT NULL DEFAULT 0,
product_id integer NOT NULL DEFAULT 0,
s_pcs real NOT NULL DEFAULT
On Monday 07 September 2009 03:25:23 Tom Lane wrote:
> Vincent de Phily writes:
> > I've been running this simple delete since yesterday afternoon :
> >> db=# explain delete from message where datetime < '2009-03-03';
> >> Seq Scan on message (cost=0.00..34131.95 rows=133158 width=6)
> >> Filter:
On Thu, Sep 10, 2009 at 10:56 AM, Tom Lane wrote:
> bricklen writes:
> > I just created a new index as Tom said, and the query *does* use the new
> > index (where ofid precedes date in the definition).
>
> And is it indeed faster than the other alternatives?
>
>regards, t
bricklen writes:
> I just created a new index as Tom said, and the query *does* use the new
> index (where ofid precedes date in the definition).
And is it indeed faster than the other alternatives?
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql-per
On Thu, Sep 10, 2009 at 10:07 AM, bricklen wrote:
> On Thu, Sep 10, 2009 at 10:02 AM, Robert Haas wrote:
>
>> On Thu, Sep 10, 2009 at 12:56 PM, bricklen wrote:
>> > On Thu, Sep 10, 2009 at 8:43 AM, Tom Lane wrote:
>> >>
>> >> bricklen writes:
>> >> > Is there any other data I can provide to sh
On Thu, Sep 10, 2009 at 10:02 AM, Robert Haas wrote:
> On Thu, Sep 10, 2009 at 12:56 PM, bricklen wrote:
> > On Thu, Sep 10, 2009 at 8:43 AM, Tom Lane wrote:
> >>
> >> bricklen writes:
> >> > Is there any other data I can provide to shed some light on this?
> >>
> >> The table and index defini
On Thu, Sep 10, 2009 at 12:56 PM, bricklen wrote:
> On Thu, Sep 10, 2009 at 8:43 AM, Tom Lane wrote:
>>
>> bricklen writes:
>> > Is there any other data I can provide to shed some light on this?
>>
>> The table and index definitions?
>>
>> The straight indexscan would probably win if the index c
On Thu, Sep 10, 2009 at 9:57 AM, Robert Haas wrote:
> 2009/9/10 :
> >> Playing around with seq_page_cost (1) and random_page_cost (1), I can
> get
> >> the correct index selected. Applying those same settings to our
> production
> >> server does not produce the optimal plan, though.
> >
> > I do
2009/9/10 :
>> Playing around with seq_page_cost (1) and random_page_cost (1), I can get
>> the correct index selected. Applying those same settings to our production
>> server does not produce the optimal plan, though.
>
> I doubt setting seq_page_cost and random_page_cost to the same value is
>
On Thu, Sep 10, 2009 at 8:43 AM, Tom Lane wrote:
> bricklen writes:
> > Is there any other data I can provide to shed some light on this?
>
> The table and index definitions?
>
> The straight indexscan would probably win if the index column order
> were ofid, date instead of date, ofid. I can't
bricklen writes:
> Is there any other data I can provide to shed some light on this?
The table and index definitions?
The straight indexscan would probably win if the index column order
were ofid, date instead of date, ofid. I can't tell if you have
any other queries for which the existing colu
> Playing around with seq_page_cost (1) and random_page_cost (1), I can get
> the correct index selected. Applying those same settings to our production
> server does not produce the optimal plan, though.
I doubt setting seq_page_cost and random_page_cost to the same value is
reasonable - random a
On Wed, Sep 9, 2009 at 6:15 AM, Reydan Cankur wrote:
> Hi,
>
> I am running PostgreSQL-8.4.0 on a SMP Server which has 32 processors
> (32X2=64 cores). I am working on database parallelism and I need to do
> profiling in order to find the relevant parts to parallelize. I wrote 15
> queries which a
Hi Tomas,
2009/9/10
> > default_statistics_target = 100 (tried with 500, no change). Vacuum
> > analyzed
> > before initial query, and after each change to default_statistics_target.
>
> Modifying the statistics target is useful only if the estimates are
> seriously off, which is not your case -
> default_statistics_target = 100 (tried with 500, no change). Vacuum
> analyzed
> before initial query, and after each change to default_statistics_target.
Modifying the statistics target is useful only if the estimates are
seriously off, which is not your case - so it won't help, at least not
re
In the following query, We are seeing a sub-optimal plan being chosen. The
following results are after running the query several times (after each
change).
dev1=# select version();
version
---
18 matches
Mail list logo
