On Thu, 15 Apr 2010, Kevin Grittner wrote:
Tom Lane t...@sss.pgh.pa.us 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.
On Thu, 15 Apr 2010, Tom Lane wrote:
Oleg Bartunov o...@sai.msu.su 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
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 o...@sai.msu.su writes:
below is an example of interesting query and two plans - the bad plan,
which
uses merge join and
Oleg Bartunov o...@sai.msu.su 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
On Thu, 15 Apr 2010, Kevin Grittner wrote:
Oleg Bartunov o...@sai.msu.su 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
Hello
there is significant problem in statistics I think,
Regards
Pavel Stehule
2010/4/15 Oleg Bartunov o...@sai.msu.su:
On Thu, 15 Apr 2010, Kevin Grittner wrote:
Oleg Bartunov o...@sai.msu.su wrote:
Sorry for odd names, they were generated by popular accounting
engine in Russia.
How
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 o...@sai.msu.su:
On Thu, 15 Apr 2010, Kevin Grittner wrote:
Oleg Bartunov o...@sai.msu.su wrote:
Sorry for odd names,
Oleg Bartunov o...@sai.msu.su 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
Tom Lane t...@sss.pgh.pa.us 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
Kevin Grittner kevin.gritt...@wicourts.gov 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
10 matches
Mail list logo
