 Okay so I try to start. First of all I need to say that actually I did not invent those practices. Those was invented by my beloved customers especially by application developers because I am DBA initially and I try to go through them very briefly because actually I have for lots of them and 100 or something like that but I try to select for you about I think eight or seven really best practices yeah really best worst practices and I do that quickly because actually you know it's you need to explain a lot and really hard to make people use the best practices but for worst practices people usually adopt them themselves very quickly and effectively so worst practices best practices are just boring so you need you don't need to follow them you need to implement worst practices and they really owe you to make things very bad so post-use consultants me myself for example quite nice guys I think and there are a lot of them here and maybe very happy if you will follow these worst practices so thank you in advance so let we just warm up a bit one of my favorite for years use as many count in your code especially if you have a high concurrency environment for example have you voted internet site put a lot of counts on your main page or and some most usable part of your internet site because if you show to your end user some magic figure it is very important figure free and even here you load a page and see quite different figure and spent five or ten minutes to calculate which figure is how it was changed yes he will be very thankful to you so select count is quite nice thing besides of that select count is quite not hungry for resources in PostgreSQL so you literally do not need to make full scan of the table to check the latest version to make the count and postgres will do it fast immediately just believe in this fact and all consultants will be quite happy for that you just do not need to use approximate figures from real tuples and from PJ catalog that's that's boring thing do not follow that the next one is try to create as many indexes as you can because it's boring to create indexes after you created your schema just cover one endeavor comb with some index better think you can do only just you can use Django and it will do it for you but actually indexes are quite free of any charge they do not consume the space we do not consume the shared barfers they do not bother you demil we do not slow up your postgres at all and actually if you create in advance some some indexes even for non existing queries up to mother was certainly will use them just for you you need to just to ask and pray and everything will behave everything will happen just keep calm and use more indexes it's not bad to use slightly in our index you just need to create both yeah for fields and multiple in that direction multiple in that direction and so on and so as many as you can yeah that's a simple combinatorics so next favorite maybe one of every consultant in this room will agree with me that if someone changed after vacuum off it's the beautiful thing because you actually can help your customer very fast very efficient and definitely it he will come to you because if he switches after vacuum off things will be really worse so you need to switch it off because you do not afraid big data big data is a nice trendy thing now so if you have for example one megabyte of data and then spread and huge data files consuming one terabyte of data you can call that big data and be trendy so do not afraid of brought brought is your friend and friend of your consultants actually so turn off the vacuum off this really helps it's a good recipe I can advice that every time so another nice thing is you need to replicate something you need to reinvent so on in post office is a quite stupid tall technology it has replication since maybe 15 years or maybe less or something like that people spent that time just for fun just don't borrow just create some triggers put some data through db link use zero MQ use something like that just reinvent the slowness because like young we can believe said so on is so hard to use because it was so hard to develop them so just try to repeat that one endeavor replication model implemented by developers I ever saw it just picked up several common mistakes from the slowness so you do need to you definitely need to repeat that five just move your joints or not joints or even better distinct or even better something like that into your application that's your beloved Python has kill or PHP or pearls Java whatever it's quite nice language is low level comparative to SQL and the only one thing you will need after you fetch several tables to your favorite programming language is to invent join not only one join but has joined made join maybe some another join and maybe you try to teach your application how to choose the proper way to join and basically you need to count the size of the one table count the size of another table maybe sample from time to time your tables from your favorite language then you can hire Tom Wayne to implement the postgres co optimizer in Haskell or something like that it's quite cheap but so it's reasonable price just to not to use the postgres as it's designed to be so just move the logic which database designed to implement to your favorite implication and implemented yourself never use graphical monitoring all those graphs it's a quite stupid thing because you can always log into your database grab some walks and say okay yesterday into two o'clock in the night that was screwed up that and that and even better you can not you just switch off any SMS notices from your monitoring because it was better than your boss called you and said our service is goes it goes down what's happened because with this SMS from text SMS from monitoring is just boring thing just do not use that it tells you to wake up 15 minutes before your boss will be on call and fix things quietly nobody will know what's happening it's boring it's stupid you need to make more fun from operating postgres quail so just do that never use foreign case foreign case it's a very stupid thing it actually the only one thing which can which has some border to the fantasy of developers you you can reach fast everything if you do not use foreign case so consistency in the application works always never happens that you lose some data you have some unconnected data if you will use foreign case so do not use them that makes that brings a lot of fun to your life and probably the good idea is to bet your monthly income for example to guarantee that the application will be consistent if you do not use foreign case nobody likes to do that if we're starting to talk about the month and come and I'm curious why I do not know maybe you know and finally eight is all the time I dealing with databases I see that thing I stop in 30 seconds or something like that people try to use very universal tables ID text ID block or something like that to make things even more simple ID can also be a text so ID can be now in some strange encoding non-unicode and you can try to interpret it in and decode it that always brings fun but if you try to for example to store in the text some IPs or my love timestamps that always be fun so example here is some example and so it is 21st of December and it easily can be converted from your business logic to something more peculiar than simply to 21st of December so do it and you always can find in your database some nice and funny artifacts so thank you if you have some questions or if you have some another worst practice just send it to me and I will talk about this on some another conference thank you