Re: 7.3.1 New install, large queries are slow

Поиск
Список
Период
Сортировка
От Roman Fail
Тема Re: 7.3.1 New install, large queries are slow
Дата
Msg-id 9B1C77393DED0D4B9DAA1AA1742942DA0E4C0F@pos_pdc.posportal.com
обсуждение исходный текст
Ответ на 7.3.1 New install, large queries are slow  ("Roman Fail" <rfail@posportal.com>)
Ответы Re: 7.3.1 New install, large queries are slow  ("Josh Berkus" <josh@agliodbs.com>)
Список pgsql-performance
>> It sort of feels like a magic moment.  I went back and looked through a
>> lot of the JOIN columns and found that I was mixing int4 with int8 in a
>> lot of them.

>There is note about it in the docs:
>http://www.postgresql.org/idocs/index.php?datatype.html#DATATYPE-INT
>
>I don't know if this is in a faq anywhere, but it should be. I myself have
>helped a number of persons with this. Every once in a while there come
>someone in to the #postgresql irc channel with the exact same problem. 
>Usually they leave the channel very happy, when their queries take less
>then a second instead of minutes.
>
>--
>/Dennis

I'm really surprised that this issue doesn't pop up all the time.  As the community grows, I think it will start to.  I
camevery, very close to dropping PostgreSQL entirely because of it.  Hopefully the TODO issue on implicit type casting
willmove closer to the top of the hackers list.  But I'm just a beggar so I won't pretend to be a chooser.
 
 
Back to my original problems:  I re-created everything from scratch and made sure there are no int8's in my entire
database.  I found a few more places that I could create useful indexes as well.  I didn't get to test it over the
weekend,but today I played with it for several hours and could not get the queries to perform much better than last
week. I was about ready to give up, throw Postgres in the junk pile, and get out the MSSQL CD.  
 
 
Luckily, an unrelated post on one of the lists mentioned something about ANALYZE, and I realized that I had forgotten
torun it after all the new data was imported (although I did remember a VACUUM FULL).  After running ANALYZE, I started
gettingamazing results.....like a query that took 20 minutes last week was taking only 6 milliseconds now.  That kicks
theMSSQL server's ass all over the map (as I had originally expected it would!!!).
 
 
So things are working pretty good now....and it looks like the whole problem was the data type mismatch issue.  I hate
topoint fingers, but the pgAdminII Migration Wizard forces all your primary keys to be int8 even if you set the Type
Mapto int4.  The second time through I recognized this and did a pg_dump so I could switch everything to int4.  Now I'm
goingto write some minor mods in my Java programs for PGSQL-syntax compatibility, and will hopefully have the
PostgreSQLserver in production shortly.  
 
 
THANK YOU to everyone on pgsql-performance for all your help.  You are the reason that I'll be a long term member of
thePostgres community.  I hope that I can assist someone else out in the future.  
 
 
Roman Fail
Sr. Web Application Developer
POS Portal, Inc.
 
 

В списке pgsql-performance по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Very large caches (was Re: 7.3.1 New install, large queries are slow)
Следующее
От: "Josh Berkus"
Дата:
Сообщение: Re: 7.3.1 New install, large queries are slow