Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yeah we just did it with the --link option on a 6TB database and it took like 30 seconds. Something has to be off with their OS settings or disk speeds.

The main challenge with that is running an ANALYZE on all the tables though, that took like 30 minutes during which time the DB was unusable



These days it does analyze in stages where it does multiple passes with increasing stats sampling.

From personal experience, most of the queries become useable after the first stage has completed which on my 8TB database took less than 5 minutes


We did use the --analyze-in-stages option, I think our data model is just not optimal. We have a lot of high frequency queries hitting very large tables of .5 to 1 billion rows. Proper indexing makes them fast but until all the stats are there, the frontend is unusable.


Was it unusable because cpu/io was maxed out during ANALYZE?


Analyze itself isn’t the problem.

After pg_upgrade, no stats will be available for the optimizer which means that any query will more or less sequence-scan all affected tables.


No, its the lack of stats on the tables, any query hitting a medium to large table would be extremely slow.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: