Re: TB-sized databases
От | Bill Moran |
---|---|
Тема | Re: TB-sized databases |
Дата | |
Msg-id | 20071128085441.51705627.wmoran@collaborativefusion.com обсуждение исходный текст |
Ответ на | Re: TB-sized databases (Csaba Nagy <nagy@ecircle-ag.com>) |
Ответы |
Re: TB-sized databases
|
Список | pgsql-performance |
In response to Csaba Nagy <nagy@ecircle-ag.com>: > On Wed, 2007-11-28 at 08:27 -0500, Bill Moran wrote: > > Is there something wrong with: > > set enable_seqscan = off > > ? > > Nothing wrong with enable_seqscan = off except it is all or nothing type > of thing... If that's true, then I have a bug report to file: test=# set enable_seqscan=off; SET test=# show enable_seqscan; enable_seqscan ---------------- off (1 row) test=# set enable_seqscan=on; SET test=# show enable_seqscan; enable_seqscan ---------------- on (1 row) It looks to me to be session-alterable. > if you want the big table to never use seqscan, but a medium > table which is joined in should use it, then what you do ? And setting > enable_seqscan = off will actually not mean the planner can't use a > sequential scan for the query if no other alternative exist. In any case > it doesn't mean "please throw an error if you can't do this without a > sequential scan". True. It would still choose some other plan. > In fact an even more useful option would be to ask the planner to throw > error if the expected cost exceeds a certain threshold... Interesting concept. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023
В списке pgsql-performance по дате отправления: