Embed Size (px)
Citation preview
Best practices are just boring
• Never follow them, try worst practices• Only those practices can really help you to screw the things upmost effectively
• PostgreSQL consultants are nice people, so try to make themhappy
1. Use as many count(*) as you can
• Figure 301083021830123921 is very informative for the enduser
• If it changes in a second to 30108302894839434020, it is stillinformative
• select count(*) from sometable is a quite light query• Tuple estimation from pg_catalog can never be preciseenough for you
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 atable covered with bunch of indexes
• Optimizer will definitely choose your index once you created it• Keep calm and create more indexes
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 databasewhich is 1Tb in size
• 2-3Tb RAM servers are cheap, IO is a fastest thing in moderncomputing
• Besides of that, everyone likes BigData
4. Reinvent Slony
• If you need some data replication to another database, try toimplement it from scratch
• That allows you to run into all problems, PostgreSQL havehad since introducing Slony
5. Move joins to your application
• Just select * a couple of tables into the application written inyour favorite programming language
• Than join them at the application level• Now you only need to implement nested loop join, hash joinand merge join as well as query optimizer and page cache
6. Never use graphical monitoring
• You do not need graphs• Because it is an easy task to guess what was happenedyesterday at 2 a.m. using command line and grep only
7. Never use Foreign Keys
• Consistency control at application level always works asexpected
• You will never get data inconsistency without constraints
8. Always use text type for all columns
• It is always fun to reimplement date or ip validation in yourcode
• You will never mistaken converting ”12-31-2015 03:01AM” to”15:01 12 of undef 2015” using textfields
