Lightening Talk - PostgreSQL Worst Practices
1 like351 views
The document outlines a set of intentionally poor practices for using PostgreSQL, humorously suggesting that following these 'worst practices' can lead to significant issues. Recommendations include excessive use of count(*) queries, creating numerous indexes, disabling autovacuum, and avoiding graphical monitoring. Additionally, it advocates for handling joins and data consistency at the application level and using text types for all columns, emphasizing a non-conventional approach to database management.
Lightening Talk - PostgreSQL Worst Practices
- 2. Best practices are just boring • Never follow them, try worst practices • Only those practices can really help you to screw the things up most effectively • PostgreSQL consultants are nice people, so try to make them happy
- 3. 1. Use as many count(*) as you can • Figure 301083021830123921 is very informative for the end user • If it changes in a second to 30108302894839434020, it is still informative • select count(*) from sometable is a quite light query • Tuple estimation from pg_catalog can never be precise enough for you
- 4. 2. Try to create as many indexes as you can • Indexes consume no disk space • Indexes consume no shared_bufers • There is no overhead on DML if one and every column in a table covered with bunch of indexes • Optimizer will definitely choose your index once you created it • Keep calm and create more indexes
- 5. 3. Turn autovacuum off • It is quite auxiliary process, you can easily stop it • There is no problem at all to have 100Gb data in a database which is 1Tb in size • 2-3Tb RAM servers are cheap, IO is a fastest thing in modern computing • Besides of that, everyone likes BigData
- 6. 4. Reinvent Slony • If you need some data replication to another database, try to implement it from scratch • That allows you to run into all problems, PostgreSQL have had since introducing Slony
- 7. 5. Move joins to your application • Just select * a couple of tables into the application written in your favorite programming language • Than join them at the application level • Now you only need to implement nested loop join, hash join and merge join as well as query optimizer and page cache
- 8. 6. Never use graphical monitoring • You do not need graphs • Because it is an easy task to guess what was happened yesterday at 2 a.m. using command line and grep only
- 9. 7. Never use Foreign Keys • Consistency control at application level always works as expected • You will never get data inconsistency without constraints
- 10. 8. Always use text type for all columns • It is always fun to reimplement date or ip validation in your code • You will never mistaken converting ”12-31-2015 03:01AM” to ”15:01 12 of undef 2015” using textfields