From: | "Pavel Stehule" <pavel(dot)stehule(at)hotmail(dot)com> |
---|---|
To: | ZeugswetterA(at)spardat(dot)at, kleptog(at)svana(dot)org |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Wrong plan for simple join with index on FK |
Date: | 2006-05-16 13:13:24 |
Message-ID: | BAY20-F10C299B06297B668F3A6C7F9A00@phx.gbl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > >These are all minor abberations though, on the whole the estimates
>are
> > >pretty good. Perhaps you need to tweak the values of random_page_cost
> > >and similar variables.
> >
> > Thank You, It's general problem or only mine? I have "100%"
> > standard current PC.
>
>The default random_page_cost assumes some concurrent activity. If your
>PC does nothing else concurrently, the performance of a seq scan will
>be underestimated.
>
>Try to do the statement with some concurrent disk load and you will most
>likely
>see that the 1. plan is faster. (assuming the tables are not fully
>cached)
>
>Andreas
ok. I tested it with pgbench and it's true. With -c 50 merge_join is
faster. I didn't expect it.
Thank You
Pavel
_________________________________________________________________
Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com.
http://www.msn.cz/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-05-16 13:25:52 | Re: psql feature thought |
Previous Message | Bort, Paul | 2006-05-16 13:09:51 | Re: Compression and on-disk sorting |