On Tue, Aug 13, 2013 at 4:50 PM, Tom Lane wrote:
> Scott Marlowe writes:
>> OK I'm bumping this one last time in the hopes that someone has an
>> idea what to do to fix it.
>
>> Query plan: http://explain.depesz.com/s/kJ54
>
>> This query takes 180 seconds. It loops 17391 times across the lower
>
Scott Marlowe writes:
> OK I'm bumping this one last time in the hopes that someone has an
> idea what to do to fix it.
> Query plan: http://explain.depesz.com/s/kJ54
> This query takes 180 seconds. It loops 17391 times across the lower
> index using entries from the upper index. That seems bugg
OK I'm bumping this one last time in the hopes that someone has an
idea what to do to fix it.
Query plan: http://explain.depesz.com/s/kJ54
This query takes 180 seconds. It loops 17391 times across the lower
index using entries from the upper index. That seems buggy to me.
While the exact estimate
On 08/02/2013 09:37 AM, Vik Fearing wrote:
> EXPLAIN ANALYZE
> WITH RECURSIVE
> x (start_time) AS
> (
> SELECT generate_series(1, 100)
> ),
> t (time, timeround) AS
> (
> SELECT time, time - time % 90 AS timeround
> FROM (SELECT min(start_time) AS time FROM x) AS tmp
> UNION
On Fri, Aug 2, 2013 at 3:27 PM, Scott Marlowe wrote:
> On Fri, Aug 2, 2013 at 2:51 PM, Tom Lane wrote:
>> Scott Marlowe writes:
>>> Yep. Added the indexes and performance went right into the dumper. New
>>> plan on new table with old data added in random order now looks like
>>> the old table, o
On Fri, Aug 2, 2013 at 2:51 PM, Tom Lane wrote:
> Scott Marlowe writes:
>> Yep. Added the indexes and performance went right into the dumper. New
>> plan on new table with old data added in random order now looks like
>> the old table, only worse because it's on a slower drive. Just to be
>> comp
Scott Marlowe writes:
> Yep. Added the indexes and performance went right into the dumper. New
> plan on new table with old data added in random order now looks like
> the old table, only worse because it's on a slower drive. Just to be
> complete here's the plan: http://explain.depesz.com/s/PYH N
On Fri, Aug 2, 2013 at 1:58 PM, Scott Marlowe wrote:
> On Fri, Aug 2, 2013 at 1:31 PM, Tom Lane wrote:
>> Scott Marlowe writes:
>>> I extracted all the data like so:
>>> select * into dba.pp_test_wide from original table;
>>> and get this query plan from explain analyze:
>>> http://explain.depes
On Fri, Aug 2, 2013 at 1:31 PM, Tom Lane wrote:
> Scott Marlowe writes:
>> I extracted all the data like so:
>> select * into dba.pp_test_wide from original table;
>> and get this query plan from explain analyze:
>> http://explain.depesz.com/s/EPx which takes 20 minutes to run.
>> If I extract it
Scott Marlowe writes:
> I extracted all the data like so:
> select * into dba.pp_test_wide from original table;
> and get this query plan from explain analyze:
> http://explain.depesz.com/s/EPx which takes 20 minutes to run.
> If I extract it this way:
> select tree_sortkey, product_name, deleted_
On Thu, Aug 1, 2013 at 7:22 PM, Scott Marlowe wrote:
> On Thu, Aug 1, 2013 at 5:44 PM, Tom Lane wrote:
>> Scott Marlowe writes:
>>> I am running 8.4.15 and can try 8.4.17 if some patch has been applied
>>> to it to address this issue. I just want to know should I
>>
>>> A: upgrade to 8.4.17
>>>
On 08/02/2013 03:22 AM, Scott Marlowe wrote:
> On Thu, Aug 1, 2013 at 5:44 PM, Tom Lane wrote:
>> Scott Marlowe writes:
>>> I am running 8.4.15 and can try 8.4.17 if some patch has been applied
>>> to it to address this issue. I just want to know should I
>>> A: upgrade to 8.4.17
>>> or
>>> B: cr
On Thu, Aug 1, 2013 at 5:44 PM, Tom Lane wrote:
> Scott Marlowe writes:
>> I am running 8.4.15 and can try 8.4.17 if some patch has been applied
>> to it to address this issue. I just want to know should I
>
>> A: upgrade to 8.4.17
>> or
>> B: create a self contained test case.
>
> A quick look a
Scott Marlowe writes:
> I am running 8.4.15 and can try 8.4.17 if some patch has been applied
> to it to address this issue. I just want to know should I
> A: upgrade to 8.4.17
> or
> B: create a self contained test case.
A quick look at the release notes shows no planner fixes in 8.4.16 or
8.4.
On Thu, Aug 1, 2013 at 2:40 PM, Scott Marlowe wrote:
> Howdy. I seem to have inherited this problem:
>
> http://www.postgresql.org/message-id/ef524e81-b815-4122-a337-7e50bced5...@silentmedia.com
>
> Basically a subselect with no offset is resulting in really poor
> performance with 120s queries bu
Howdy. I seem to have inherited this problem:
http://www.postgresql.org/message-id/ef524e81-b815-4122-a337-7e50bced5...@silentmedia.com
Basically a subselect with no offset is resulting in really poor
performance with 120s queries but adding an offset 0 to the inner sub
select results in 0.5s que
16 matches
Mail list logo
