Back in the 2013 I started playing with sqlalchemy to create a simple extractor from heterogeneous systems to be pushed in postgresql.
I decided to give the project a name which recalled the transformation and I called pg_chameleon.
To be honest I didn’t like sqlalchemy. Like any other ORM adds an interface to the data layer with a mental approach to the data itself. I lost the interest to developing a migrator very soon, and after all there are thousands of similar tools thousands of times better than mine (e.
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.
Thanks to the Ferrara’s University, departement of Engineering I’ll attend to another evening with PostgreSQL.
This time the event will be a seminary with all talks made by me.
The first talk will cover our beloved elephant’s history.
The second talk will look to the engine with particular attention to the MVCC and the memory manager.
The final talk will cover thebackup and recovery with pgdump and the streaming replication.
I’ve been busy recently and I failed to update on the last meetup news.
I apologise for that.
We had a very interesting meetup in January.
Alexey Bashtanov explained how the grouping works in postgres and how to improve or even re implement in C the grouping functions.
On the meetup page there are the pictures from the meeting.
The presentation’s recording is available thereand the slides are free to download on slideshare there.
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
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.
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.
What follows is the synthesis of several years of frustration. Before you start reading please note that the things written in the dark age section do not apply for the high end environments like Oracle. That’s mostly because starting an Oracle project without a DBA on board is an interesting and creative way to get bankrupt in few months. Obviously things evolves and maybe in the next decade my Oracle fellows will join me in this miserable situation.
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.