Sorry, I used random_page_cost=2, while random_page_cost=3 didn't help.
Oleg
On Fri, 16 Apr 2010, Oleg Bartunov wrote:
On Thu, 15 Apr 2010, Tom Lane wrote:
Oleg Bartunov writes:
below is an example of interesting query and two plans - the bad plan,
which
uses merge join and big sorting, too
On Thu, 15 Apr 2010, Tom Lane wrote:
Oleg Bartunov writes:
below is an example of interesting query and two plans - the bad plan, which
uses merge join and big sorting, took 216 sec, and good plan with merge join
disabled took
8 sec.
The "good" plan seems to be fast mainly because of heavil
On Thu, 15 Apr 2010, Kevin Grittner wrote:
Tom Lane wrote:
I'm not sure how much it would help to increase the statistics
targets, but that would be worth trying.
Setting statistics to 1000 helps for that particular reduced query, but
full query (attached) is out of luck.
I notice that t
"Kevin Grittner" writes:
> What's up with the sort of _accrged7200 (in the slower plan) taking
> in 3.5 million rows and putting out 1 row? There's something there
> I'm not understanding.
It's under a merge join, so what probably happened is that the first
row from that side had a larger key th
Tom Lane wrote:
> I'm not sure how much it would help to increase the statistics
> targets, but that would be worth trying.
I notice that the scan rowcount estimates are very accurate, there's
that one hash join result that's way off, though.
What's up with the sort of _accrged7200 (in the s
Oleg Bartunov writes:
> below is an example of interesting query and two plans - the bad plan, which
> uses merge join and big sorting, took 216 sec, and good plan with merge join
> disabled took
> 8 sec.
The "good" plan seems to be fast mainly because of heavily cached inner
indexscans. If t
On Thu, 15 Apr 2010, Pavel Stehule wrote:
Hello
there is significant problem in statistics I think,
Ah, you're right !
Regards
Pavel Stehule
2010/4/15 Oleg Bartunov :
On Thu, 15 Apr 2010, Kevin Grittner wrote:
Oleg Bartunov wrote:
Sorry for odd names, they were generated by popular
Hello
there is significant problem in statistics I think,
Regards
Pavel Stehule
2010/4/15 Oleg Bartunov :
> On Thu, 15 Apr 2010, Kevin Grittner wrote:
>
>> Oleg Bartunov wrote:
>>
>>> Sorry for odd names, they were generated by popular accounting
>>> engine in Russia.
>>
>> How much of that can
On Thu, 15 Apr 2010, Kevin Grittner wrote:
Oleg Bartunov wrote:
Sorry for odd names, they were generated by popular accounting
engine in Russia.
How much of that can you trim out and still see the problem?
It's difficult, since I don't know semantics of data. I reduced query, though.
que
Oleg Bartunov wrote:
> Sorry for odd names, they were generated by popular accounting
> engine in Russia.
How much of that can you trim out and still see the problem?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://w
Hi there,
below is an example of interesting query and two plans - the bad plan, which
uses merge join and big sorting, took 216 sec, and good plan with merge join disabled took
8 sec. Sorry for odd names, they were generated by popular accounting
engine in Russia. 8.4.3 and HEAD show the same
11 matches
Mail list logo
