Friday 14th August we kicked off the Brighton PostgreSQL Meetup.
We had a nice evening with cool people all togheter discussing about PostgreSQL and how we can run effectively the meetup.
We decided to have a regular monthly meetup hosted around Brighton, possibly, by
companies or any suitable venue.
The next meetup will be the
25th of September and this time there will be some PostgreSQL talks. The
general interest favours the standby servers and the
streaming replication. Another topic could be the query planning and execution.
I can cover both of the topics. We just need to decide how many talks will be in one hour session.
After the meetup we’ll head to the nearest pub for a nice beer.
I can only say a big thank you, to all the meetup members.
That’s all for now.
Database administration is weird, nobody can tell what does looks like. You have to find out by yourself.
Monday 17 August 2015
Wednesday 12 August 2015
Meet Marvin
There is just one day left and we'll start the Brighton PostgreSQL Meetup. I invested some resources in this project like and I truly believe it can be a success.
I still can't believe that in just one month 25 people already have shown the interest on being part of the Brighton PostgreSQL Group. And today another nice suprise. I received the new shiny mascot for our group.
He's Marvin, the sea elephant. The author if this fantastic drawing is Elena, an incredibly talentuous artist from Italy.
I've also opened a twitter account for our social media presence.
So we are ready to start. I'm very excited and I'll write a detailed report of our first meetup in few days.
I still can't believe that in just one month 25 people already have shown the interest on being part of the Brighton PostgreSQL Group. And today another nice suprise. I received the new shiny mascot for our group.
He's Marvin, the sea elephant. The author if this fantastic drawing is Elena, an incredibly talentuous artist from Italy.
I've also opened a twitter account for our social media presence.
So we are ready to start. I'm very excited and I'll write a detailed report of our first meetup in few days.
Thursday 6 August 2015
Directory format and default compression
After upgrading some clusters to PostgreSQL 9.4.4 I noticed an increase of the database backup. Because the databases are quite large I'm taking the advantage of the parallel export introduced with PostgreSQL 9.3.
The parallel dump uses the PostgreSQL's snapshot export with multiple backends. The functionality requires the dump to be in directory format where a toc file is saved alongside with the compressed exports, one per each table saved by pg_dump.
Initially I believed that the latest release introduced a change in the default compression level. However I noticed that using the custom format the resulting file was smaller.
For testing purposes I've created a database with two tables big 700MB each one. Using the custom format with the default compression level they are saved in 442 MB. The directory format stores the same data in 461MB, +4%.
After some research I spotted a recent change introduced in the version 9.4.2.
In pg_dump, fix failure to honor -Z compression level option together with -Fd
With another search, this time on the committers mailing list, I found this commit .
Basically the change in the 9.4.2 "ignored the fact that gzopen() will treat "-1" in the mode argument as an invalid character", causing the compression level to be set to 1, the minimum.
The fix is already committed and should appear in the next minor release. Until then, if using the directory format, the workaround is to pass the flag -Z 6 to pg_dump.
The bug has been backpatched to the version 9.1. However I've never noticed this issue until I switched from the 9.3.9 to the 9.4.4.
The parallel dump uses the PostgreSQL's snapshot export with multiple backends. The functionality requires the dump to be in directory format where a toc file is saved alongside with the compressed exports, one per each table saved by pg_dump.
Initially I believed that the latest release introduced a change in the default compression level. However I noticed that using the custom format the resulting file was smaller.
For testing purposes I've created a database with two tables big 700MB each one. Using the custom format with the default compression level they are saved in 442 MB. The directory format stores the same data in 461MB, +4%.
After some research I spotted a recent change introduced in the version 9.4.2.
In pg_dump, fix failure to honor -Z compression level option together with -Fd
With another search, this time on the committers mailing list, I found this commit .
Basically the change in the 9.4.2 "ignored the fact that gzopen() will treat "-1" in the mode argument as an invalid character", causing the compression level to be set to 1, the minimum.
The fix is already committed and should appear in the next minor release. Until then, if using the directory format, the workaround is to pass the flag -Z 6 to pg_dump.
The bug has been backpatched to the version 9.1. However I've never noticed this issue until I switched from the 9.3.9 to the 9.4.4.
Subscribe to:
Posts (Atom)