planetpostgresql

I’ll be at the University of Ferrara Saturday 9th of January for a PostgreSQL afternoon. This is the confirmed schedule. 15:00 - Federico Campoli: PostgreSQL, the big the fast and the (NOSQL on) Acid 15:40 - Michele Finelli: The PostgreSQL’s transactional system 16:20 - Coffee break / general chat 16:40 - Federico Campoli: Streaming replication 17:30 - Federico Campoli: Query tuning in PostgreSQL 18:00 - Michele Finelli: An horror fairy tale: how we have lost a database

Three days to go for the next Brighton PostgreSQL meetup. I’ll run a live hangout of the talk. You can join the event there. https://plus.google.com/events/cge4691km5qm8euj4erkcp7jecs The record will become available on youtube shortly after the talk’s end.

November 27th at 19.00 GMT I’ll talk at theBrighton PostgreSQL meetup. This time the group chosen the streaming replication as topic. The talk will cover the PostgreSQL write ahead logging and the crash recovery process. The audience will learn how to setup a standby server using the streaming replication and how to troubleshoot it. Please RSVP here.

Like previously said, the next Brighton PostgreSQL meetup will be September 25th at 7 pm BST. The topic chosen by the member is the query planning and execution in PostgreSQL. I will do the presentation exploring the various steps a query passes through from the client to the execution. I’ll also explain how to read the execution plan and why sometimes the executor seems to ignore the indices put in place for speeding up the operations.

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.

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.

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.

After a while I finally started a PostgreSQL Meetup in Brighton. I reckon there are several people interested in PostgreSQL in the UK and I’ve met many of them in the Sussex area. I’m quite new to the Meetup platform so I still need to learn how to use it correctly. However, anybody is absolutely welcome to help to organise a PostgreSQL community in the area. The link is here. http://www.

INSERT The INSERT statement is composed by two elements, the attribute list and the values list. The lists are positional. The formatting should mark clearly the various elements of the query in order to make it simpler to spot the correspondence between the attribute and the value. After the words INSERT INTO there is one space followed by the table’s name After the table’s name there is one carriage return The attributes if present are enclosed between round brackets indented one tab from the word INSERT The attribute’s list indents one tab from the round brackets The attributes indent one tab fro the round brackets and are separated by a carriage return The word VALUES indents at the same level of INSERT and is followed by a carriage return The value’s list is surrounded by round brackets indented one tab from the word VALUE The values indent one tab fro the round brackets and are separated by a carriage return UPDATE The WHERE condition on the update is the same of the SELECT.

WITH statements Because the WITH statement works like having a temporary table, the formatting will follow rules similar to the CREATE TABLE statement. • Between the WITH and the alias there is a tab followed by the word AS and a carriage return • The round brackets surrounding the inner query indent one tab from the alias • The inner query indents one tab from the round brackets Conclusions This coding style is at first sight complex and with some drawback as it can slow down the coding process because of more keystrokes required for the uppercase and the carriage return.