| 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: | Whole Thread | Raw Message | 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 |