Re: join over 12 tables takes 3 secs to plan
От | scott.marlowe |
---|---|
Тема | Re: join over 12 tables takes 3 secs to plan |
Дата | |
Msg-id | Pine.LNX.4.33.0301030958540.13778-100000@css120.ihs.com обсуждение исходный текст |
Ответ на | Re: join over 12 tables takes 3 secs to plan (Hilmar Lapp <hlapp@gmx.net>) |
Ответы |
Re: join over 12 tables takes 3 secs to plan
|
Список | pgsql-performance |
On Thu, 2 Jan 2003, Hilmar Lapp wrote: > > On Thursday, January 2, 2003, at 04:01 PM, Ron Johnson wrote: > > > > > Could it be that PG isn't the proper tool for the job? Of course, > > at USD20K/cp, Oracle may be slightly out of budget. > > > > > > We are in fact an Oracle shop, but the application I tried to get > running (http://trackplus.sourceforge.net/) I wanted to run on an OSS > RDBMS so that I could easily move it onto my laptop etc (BTW apparently > it was primarily developed on InterBase/Firebird). Anyway, I was able > to cut the planning time for those queries in half by setting > geqo_pool_size to 512. However, now it gets stuck for an excessive > amount of time after the issue update page and I have no idea what's > going on, and I'm not in the mood to track it down. So finally I'm > giving up and I'm rolling it out on MySQL on which it is working fine, > even though I don't like MySQL to say the least. Have you tried it on firebird for linux? It's an actively developed rdbms that's open source too. If this was developed for it, it might be a better fit to use that for now, and then learn postgresql under the less rigorous schedule of simply porting, not having to get a product out the door. Is an explicit join the answer here? i.e. will the number of rows we get from each table in a single query likely to never change? If so then you could just make an explicit join and be done with it.
В списке pgsql-performance по дате отправления: