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
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
Hi Tomas,
2009/9/10 t...@fuzzy.cz
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
On Wed, Sep 9, 2009 at 6:15 AM, Reydan Cankur reydan.can...@gmail.com 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
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
bricklen brick...@gmail.com 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
On Thu, Sep 10, 2009 at 8:43 AM, Tom Lane t...@sss.pgh.pa.us wrote:
bricklen brick...@gmail.com 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
2009/9/10 t...@fuzzy.cz:
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
On Thu, Sep 10, 2009 at 9:57 AM, Robert Haas robertmh...@gmail.com wrote:
2009/9/10 t...@fuzzy.cz:
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
On Thu, Sep 10, 2009 at 12:56 PM, bricklen brick...@gmail.com wrote:
On Thu, Sep 10, 2009 at 8:43 AM, Tom Lane t...@sss.pgh.pa.us wrote:
bricklen brick...@gmail.com writes:
Is there any other data I can provide to shed some light on this?
The table and index definitions?
The straight
On Thu, Sep 10, 2009 at 10:02 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Sep 10, 2009 at 12:56 PM, bricklen brick...@gmail.com wrote:
On Thu, Sep 10, 2009 at 8:43 AM, Tom Lane t...@sss.pgh.pa.us wrote:
bricklen brick...@gmail.com writes:
Is there any other data I can provide
On Thu, Sep 10, 2009 at 10:07 AM, bricklen brick...@gmail.com wrote:
On Thu, Sep 10, 2009 at 10:02 AM, Robert Haas robertmh...@gmail.comwrote:
On Thu, Sep 10, 2009 at 12:56 PM, bricklen brick...@gmail.com wrote:
On Thu, Sep 10, 2009 at 8:43 AM, Tom Lane t...@sss.pgh.pa.us wrote:
bricklen
bricklen brick...@gmail.com 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
On Thu, Sep 10, 2009 at 10:56 AM, Tom Lane t...@sss.pgh.pa.us wrote:
bricklen brick...@gmail.com 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?
On Monday 07 September 2009 03:25:23 Tom Lane wrote:
Vincent de Phily vincent.deph...@mobile-devices.fr 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
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
Grzegorz Jaśkiewicz gryz...@gmail.com 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
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 periods p on
18 matches
Mail list logo
