Resultados 1 a 2 de 2
  1. #1
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010

    "Inside" Postgres

    What is it like to work with Michael Stonebraker?
    Asked by Miguel Paraz

    by Greg Kemnitz

    I worked for Postgres and Prof. Stonebraker from early 1989 to early 1992 as a research staffer (the "Chief Programmer"), and later worked with Illustra as a consultant. As the head of the Postgres Project, Prof. Stonebraker was my boss. (Sorry, my answer is a bit wandering, but I figured some context is needed...)

    First, a bit about the Postgres Project: when I was there, I figured that the reason Prof. Stonebraker hired (rather expensive) staffers like me was that many similar projects essentially end up with one of the grad students becoming the de facto project manager. (The chief investigating professor is usually too busy being an "outward facing" leader, fundraising, overseeing research, working on papers and books, etc.) This works great until that person finishes their PhD and leaves, which disrupts the continuity of the project. Many projects end up dying when this happens.

    Basically, my job was to the the main contact for our users, and helped keep our environment running. I also cleaned up tons of code, fixed lots and lots of bugs, "owned" QA and testing, and when a grad student left, I had an odd "triage" role: either the code he implemented was useful and I cleaned it up, or it wasn't salvageable and I ripped it out. (CS grad students vary dramatically in their coding skills.) One thing that was a big issue was that much of Postgres was originally coded in Lisp, which proved to be a disaster, and the Lisp was converted to C by using a code generator. Getting this code back to a state where it could be used "for real" took a lot of work by the team; I arrived just after the code was initially converted to C.

    (You can still see some of the "Lispiness" even in PostgreSQL today, particularly in the "nodes" stuff used in the executor and optimizer. This actually is useful, and I still use "S-expression" data structures for representing parsetrees and execution plans for other db engines I worked on.)

    Another aspect of the Postgres Project was that Prof. Stonebraker wants to see ideas and theories implemented with working code, ideally being used by "real" users. He was emphatically unimpressed with whiteboard and paper theoreticians who didn't attempt to render their ideas into code, preferably used for a real project. This was his approach to the Ingres project, which became the core of Relational Technologies/Ingres Inc (his first company) and was followed with the Postgres project. Prof Stonebraker is an engineer at heart and approaches database problems as engineering problems, not as "theory" problems, and is intensely impatient with "empty" theory.

    As a boss, Prof. Stonebraker was quite good to work for, and knew the code extremely well, especially considering that he didn't actually write code at Postgres. He knew who wrote the code and had a very good idea of their strengths and weaknesses, to the point where if we discussed bugs in staff meetings, he'd point us at possible sources of the bugs that were quite often right.

    He could be ruthless to people who weren't "his people", which I saw happen at several conferences, but if you were "his people", he'd treat you extremely well and protect you from academic and bureaucratic "attacks" (which happened with me a couple of times).

    One other aspect of working with Prof. Stonebraker was I learned that "marketing" matters in academia as well as business. An example: originally, Postgres was described as an "extended relational" database, in that it allows user-defined datatypes and has lots of extensibility and dynamism. But one day Prof. Stonebraker came back from a meeting with funders at DARPA and NSF, and said "we have to call Postgres 'object relational' since the funding action is in the object world".

    So, we did. We added table inheritance and methods to Postquel (Postgres' query language) to make "object" a reasonable claim, and all the papers that we wrote afterward used "object relational" to describe Postgres.

    As for Illustra, I got a bit full of myself and mostly missed the boat there, but I ended up working there as a consultant about a year or so after it started. By then, he was an adviser and on the company board and wasn't there often, so I didn't see him much after the Berkeley days.

    Written 17 Oct, 2014

  2. #2
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010

Permissões de Postagem

  • Você não pode iniciar novos tópicos
  • Você não pode enviar respostas
  • Você não pode enviar anexos
  • Você não pode editar suas mensagens