"Carson, Leonard" writes:
> Here are the 3 views and some timing notes:
> http://pgsql.privatepaste.com/decae31693#
That doesn't really leave us any wiser than before, unfortunately.
It's clear that the root of the problem is the drastic underestimation of
the size of the rq/a join, but it's not
Would not be the case slightly decrease the shared buffer, lower your
checkpoints_timeout for eg 5 minutes or decrease checkpoints_segments and
set the checkpoint_completation_target to 0.5 to not mess up the next
checkpoints?
What logs tell me is that a checkpoint occurs immediately to the other
I think I understand now after reading the notes here on the merge join
algorithm:
https://github.com/postgres/postgres/blob/4ea51cdfe85ceef8afabceb03c446574daa0ac23/src/backend/executor/nodeMergejoin.c
The index scanning node doesn't know the max id of the vehicle table and so
can't know when t
17.03.2015 13:22, Sergey Shchukin пишет:
05.03.2015 11:25, Jim Nasby пишет:
On 2/27/15 5:11 AM, Sergey Shchukin wrote:
show max_standby_streaming_delay;
max_standby_streaming_delay
-
30s
We both need to be more clear about which server we're talking about
(ma
Here are the 3 views and some timing notes:
http://pgsql.privatepaste.com/decae31693#
thanks, lcarson
On Mar 18, 2015, at 3:41 PM, Tom Lane
mailto:t...@sss.pgh.pa.us>> wrote:
"Carson, Leonard" mailto:lcar...@sdsc.edu>> writes:
There is only one server at this point. The 8.4 machine was upgraded
Thanks Tom, that sounds like what is happening. Some additional
comments/questions inline.
Tom Lane-2 wrote
> I think what must be happening is that the planner notes the maximum
> possible value of v.id and supposes that the mergejoin will stop far short
> of completion because v.id spans just a
I wrote:
> [ assorted possible workarounds ]
Actually, an easy fix might be to create a 2-column index on
usagestats(type, tid). I think the planner should be able to
use that to produce sorted output for the mergejoin, and you'd
get the best of both worlds, because the indexscan will stop
immedi
Jake Magner writes:
> I am having problems with a join where the planner picks a merge join and an
> index scan on one of the tables. Manually disabling merge joins and running
> the query both ways shows the merge join takes over 10 seconds while a hash
> join takes less than 100ms. The planner t
random_page_cost = 4
seq_page_cost = 1
Regardless of the the choice to use the index scan and random access to the
rows, how come in the second query with the freq > -1 condition, it accesses
far fewer pages with the same index scan even though no rows are filtered
out?
Thanks
--
View this mes
