The next meetup at Brighton will be Friday 14th October at 19.30.
Daniele Varrazzo will kindly talk about the most popular PostgreSQL driver in the python universe.
Psycopg is the most used PostgreSQL driver for the Python programming language.
As a driver it stays at a relatively low level, allowing to use all the features offered by the database. Behind the scenes, it does its best to convert the rich Python data model into the likewise rich PostgreSQL data model:
After the summer break the Brighton PostgreSQL meetup restarts with the monthly technical talks.
This time is my round again. I’ll speak on how to scale the backup and recovery on large postgres installations.
Actually this is the talk I’ve submitted to the european pgconf.
I made the talk in a storytelling form in order to avoid to bore the audience to the death. The talk should be quite entertaining with explanation of the issues solved by the DBA over the years.
This second meetup went very well. The audience was interested and we had fun time thanks to the beer and pizzas offered alongside with the venue by our sponsor brandwatch.
Here a couple of pictures from the meetup.
The recording worked much better than the previous time, here’s the presentation’s video. We’ll meet again shortly for a nice beer. Next technical talk will be probably in January.
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.
