The acronym RTFM stands for Read The Fucking Manual. It’s quite obvious that reading the manual is the perfect approach for finding the correct information or at least a hint for finding the solution.
The false confidence or a lack of humbleness make people to forget how important is to read the documents. Understanding the documents is the next step, and is not simple indeed. In particular if the background is poor or the reader have preconceptions which alter the word meanings.
The failure is not an option. Despite this statement is quite pretentious is also the rule number zero of any decent DBA. The task failure, should this be a simple alter table or an emergency restore, is not acceptable. The database is the core of any application and therefore is the most important element of the infrastructure.
In order to achieve this impossible level, any task should be considered single shot.
I’ve already started writing the second volume of the database administration series.
The first volume was quite basic with enough information to be useful but not too much to scare people.
The second volume is strongly focused on the database administration and I decided to start it with a chapter explaining what it means to be a DBA.
Probably this will dissuade many people to start this exciting career.
So, here we go again.
Finally I finished the first volume of the PostgreSQL book administration.
The book is free to download on slideshare or, if you want the hard copy there is the button to order on lulu.com.
I’ll build an ebook version in the next days and I’ll make it available on amazon’s kindle and the kobo.
I hope this book will spread the knowledge on PostgreSQL.
Anyway, I’ve not finished. I’ve already started a second volume and a manual for the developers willing to learn the noble art of the SQL writing.
So finally PostgreSQL 9.4 has been released. This version introduces a new schema less type, the jsonb which joins the other fantastic features abused and misused by the developers all around the globe.
The DBA improvements in this release is much more interesting and can push seriously the adoption in the enterprises of this DBMS.
Alter system Finally is possible to change the postgresql.conf settings using the ALTER SYSTEM SET command.
Because an industrial action is taking place in Italy my flight was cancelled.
I’m not going to the Linux Day in person but, thanks Google, I should be able to talk.
PostgreSQL, The Big, The Fast and The Ugly from Federico Campoli
I’ll start Saturday 15.00 CEST.
After a couple of month dealing with MySQL and wondering how is possible to rely on such fragile system, I’m back to PostgreSQL.
I had the fantastic news my PostgreSQL and big data talk was accepted at the Italian Linux Day 2014 organised by the Ferrara Linux User Group.
The talk will be obviously in Italian and will be very likely available in streaming.
The talk schedule is very interesting indeed and covers the entire day.
The book is now complete. There’s still a lot to do for reviewing the writing and fixing the bad grammar. Anyway is about 107 pages and I’m pretty satisfied. I’ve worked on this document for 4 months in my spare time and I became more confident with my English during the writing.
So, what’s next? I’ll spend the next couple of weeks reviewing and fixing the book. After that I’ll put the pdf on lulu.
This is almost the entire chapter 11. I’m still writing the final section, I’d like to put into a separate post though. I’ve also almost finished the restore’s performance. After this the book is complete. I will start a review to make it a decent writing before publishing onto lulu.com and amazon kindle.
I’m not sure amazon permits to sell books for free I’ll find a solution anyway. A couple of things to know before start coding… This chapter is completely different from the rest of the book.
Foreign keys A foreign key is a constraint enforced using the values another table’s field. The classical example is the tables storing the addresses and cities. We can store the addresses with the city field, inline.
Being the city a duplicated value over many addresses, this will cause the table bloat by storing long strings, duplicated many and many times, alongside with the the address. Defining a table with the cities and referencing the city id in the addresses table will result in a smaller row size.
