Continuing my serie of interviews with PostgreSQL Developers, i have the pleasure to talk with Mr. Bruce Monjiam (in the FAQ of his blog, he tell us that the English pronunciation of Momjian is is MOM-jin). In the past, I talk with Josh Berkus and Euler Taveira (in portuguese, only).

Bruce Momjian is a co-founder of the PostgreSQL Global Development Group, and has worked on PostgreSQL since 1996. He is the author of PostgreSQL: Introduction and Concepts, published by Addison-Wesley. Bruce is employed by EnterpriseDB. Previously, he was employed by SRA Japan and Great Bridge LLC, both PostgreSQL support companies. He has spoken at many international open-source conferences. Prior to his involvement with PostgreSQL, Bruce worked as a consultant, developing custom database applications for some of the world’s largest law firms. Prior to this, he was a high school computer science teacher and holds a Masters in Education.

2 - When did You become a PostgreSQL developer?

Após a Entrevista com Josh Berkus, estou trazendo aqui uma entrevista com um desenvolvedor brasileiro de peso, o Sr. Euler Taveira que tive o prazer de conhecer no último CONISLI.

Euler é engenheiro de computação pela UFG, atualmente analista de sistemas na OVG, especialista em banco de dados e entusiasta do software livre.

1- Como você começou a utilizar Software Livre?

O meu primeiro contato com software livre foi em 1998 quando entrei na faculdade. No laboratório tinhamos Solaris, AIX, Conectiva 3.0 (Guarani) e Slackware 3.5 utilizando softwares GNU.

2- Quando você começou a utilizar e desenvolver o PostgreSQL?

Comecei a utilizar o PostgreSQL em 1999, em um projeto de tutores inteligentes. A iteração foi tanta que comecei a *timidamente* contribuir com código; inicialmente foi a tradução e depois algumas pequenas funcionalidades.

3- Você participa da tradução da documentação do PostgreSQL. Quais são as maiores dificuldades neste trabalho?

O processo de tradução de documentação técnica não é fácil; a do PostgreSQL não é diferente. Talvez a maior dificuldade seja as novas expressões. A cada nova versão peço sugestões para as novas expressões, pois nem sempre elas soam bem (veja o caso de “role”); e um dos objetivos de uma tradução é que ela reproduza o texto original de forma natural e fidedigna.

4- Você tem atuado nas opções de localização do PostgreSQL, com boas
novidades na versão 8.2. O que você tem preparado para a versão 8.3 e quais são seus planos para futuras versões?

Sim. Você observou bem . Para a versão 8.3 estou preparando dois patches: um para reimplementar o modificador TM da função to_char() (na atual é utilizado o LC_MESSAGES — que depende de tradução e, nesta nova versão usarei o LC_TIME — que não depende [já está traduzido]) e o outro é a localização do tipo money. Um patch para especificação do diretório do log de transação durante o initdb já está no CVS. Para versões futuras, costumo focar naquilo que me incomoda . Alguns exemplos, são permissões em colunas, funções de agregações novas como ROLLUP e CUBE. Queria ter um tempo para trabalhar nos projetos de replicação como Slony e pgpool, mas infelizmente as madrugadas e os fins de semana não são suficientes.

5- Qual codificação de caracteres você recomenda para se utilizar com
PostgreSQL?

Eu recomendaria o ISO-8859-1 .Muitos podem querer me jogar pedra nesta hora, mas tenho minhas razões. Não acho o código de suporte a UTF-8 sólido o bastante no PostgreSQL. Por quê? Em algumas versões anteriores vimos correções relacionadas a caracteres UTF-8 inválidos sendo aceitos como válidos. Então eu recomendo que se utilize UTF-8 somente se precisar de UTF-8. Talvez em versões futuras eu me sinta seguro em utilizar UTF-8 (isso não quer dizer que eu não o utilizo; e sim, que uso somente quando necessário).

6- Você já deu palestras sobre desempenho com PostgreSQL, você acredita que o desempenho do PostgreSQL é superior a dos demais concorrentes do mercado?

Hmmm. Desempenho é relativo ao ambiente que se está analisando (data warehousing, OLTP, OLAP). Em todos esses ambientes o PostgreSQL está melhorando o seu desempenho a cada versão. Quanto aos seus concorrentes, creio que o desempenho é superior em alguns aspectos, mas não posso provar com benchmarks porque a licença destes concorrentes não me permite tal façanha. Posso dizer que já tive clientes satisfeitos com a performance do PostgreSQL após a migração desses outros bancos de dados.

7- Você também já tem uma boa experiência com o Slony. Em quais situações você recomenda o uso do Slony?

Soluções sólidas de replicação é o que definitivamente faltava para o PostgreSQL ganhar o ambiente corporativo. O Slony foi concebido em um momento que isso era almejado. Ele é recomendado em um cenário onde uma pequena perda de dados é aceitável (replicação assíncrona) e a alta disponibilidade (operação 24×7) é desejável. Ele também é muito útil para migração entre versões sem precisar de um tempo de manutenção alto (para fazer a cópia de segurança aka backup e depois a restauração).

8- Você acredita que o projeto do Slony II com uma proposta de replicação multi-master se tornará uma realidade?

Tem um bom tempo que ele está inativo. O problema de sincronismo entre máquinas diferentes é uma coisa difícil de lidar. A proposta de implementação é boa, mas muito complexa.

9- Existem várias ferramentas de replicação para PostgreSQL, livres e
proprietárias. Você acredita que uma delas se tornará mais popular em
relação às demais ou cada se aplica melhor a casos distintos?

Replicação é um conceito muito amplo. Acho que teremos 2 ou 3 ferramentas predominantes, pois temos 2 modelos de replicação (síncrono e assíncrono) distintos.

10- Você também trabalha com outros SGDBs também? Em quais casos você diria que o PostgreSQL pode não ser a melhor opção?

Sim. Minha especialidade é banco de dados então conheço bem alguns deles. O PostgreSQL não é uma boa opção quando utilizado para armazenamento hierárquico (SQL não foi feito pra isso — neste caso sugiro LDAP) e quando o negócio tem que ter uma garantia (pecuniária) caso o sistema de banco de dados sofra perdas (versões comerciais do PostgreSQL podem suprir este nicho).

11- Você acredita que a popularidade do PostgreSQL no Brasil já o coloca como uma das principais opções de mercado? O que falta para o PostgreSQL se tornar uma opção mais popular no Brasil?

Sim. E o “boom” começou exatamente a partir da versão 8.0 (versão nativa para Windows). Muitos desenvolvedores de software no Brasil não utilizavam o PostgreSQL, porque não existia uma versão para Windows (ambiente de desenvolvimento da maioria dos desenvolvedores). O uso estava restrito a poucos desenvolvedores em corporações de médio e grande porte. O crescimento da popularidade, também se deve a grande comunidade ativa de PostgreSQL no Brasil. Documentação e artigos na nossa língua nativa também são fatores que contribuem para popularização.

12- A comunidade brasileira do PostgreSQL tem crescido bastante nos últimos anos com participação intensa nos eventos de Software Livre. O que você espera da comunidade em 2007?

A comunidade de PostgreSQL brasileira é uma das maiores do mundo; e a tendência é crescer mais ainda. Como? Organização. A cada novo evento arrebanhamos novos adeptos que estão dispostos a ajudar nessa organização. Não é por acaso que somos o banco de dados com maior número de palestras nestes eventos. Agradeço a todos aqueles que se empenham para que isso seja possível.

Esta é a minha primeira entrevista com desenvolvedores do PostgreSQL. Eu espero conversar com muitos desenvolvedores do núcleo, grandes desenvolvedores, desenvolvedores brasileiros e desenvolvedores de projetos interessantes relacionados com o PostgreSQL. No momento este é apenas o primeiro, mas você pode esperar ao menos uma por mês.

English note: The original version of this interview in english is posted here.

Josh Berkus é um dos sete membros do time do núcleo do PostgreSQL, que controlam as versões lançadas do Projeto PostgreSQL. Ele é também líder na Sun Microsystems e tem sido consultor de bancos de dados por mais de uma década. Josh também é um ótimo cozinheiro. Note que Josh fala apenas por si próprio, não pela Sun Microsystems ou pelo Projeto PostgreSQL.

1 - Quando você começou a trabalhar com computadores e quando começou a utilizar Software Livre?

Eu comecei trabalhando com computadores em 1981… com o Commodore Vic20. No colegial eu tive um computador de 8 bits Atari, e fiz muitos hacks no seu hardware, assim como fiz alguma programação de jogos em Basic e assembler.

Eu comecei com Software Livre em 1998. Neste tempo eu era um consultor de pequenos negócios e ONGs construindo pequenas aplicações em bancos de dados e incapaz de tolerar os crescentes preços e aumentos de erros - Eu percebi que se eu continuasse utilizando Microsoft, eu iria a bancarrota, enlouquecer, ou ambos. Então eu troquei o MS SQL Server e o Visual Basic para o PostgreSQL 7.0, Linux 2.2 e PHP 3. Depois eu utilizei um pouco de Perl.

Um dos clientes rodando minhas primeiras aplicações em PostgreSQL está rodando até hoje (uma agência de empregos). Um dos meus clientes em plataforma Microsoft também … mas eles tiveram que contratar um funcionário em tempo integral para manter o software em Visual Basic.

Foi também quando eu me envolvi com a comunidade. Durante o mesmo mês, eu descobri erros no MS SQL Server 7 e no PostgreSQL 7.1. Minha postagem no comp.databases.microsoft.sqlserver foi silenciosamente apagada do fórum MSDN, e o erro nunca foi corrigido. No PostgreSQL, Tom Lane (que ingressou no projeto apenas três meses antes) confirmou o erro em horas e me providenciou um path experimental. Foi quando eu fui fisgado.

2 - Como você vê o mercado de bancos de dados livres e proprietários?

Todos os bancos de dados SQL estarão comoditizados nos próximos 10 anos. Isto é, eu espero que em 2015 haverão apenas quatro tipos de bancos de dados em uso: código aberto, shareware e freeware (como o DB2 express), baixo custo e especializado (como o Filemaker e Pervasive), e bancos de dados legados não mais mantidos.

Isto ocorre principalmente devido aos requisitos de um servidor de banco de dados relacional serem bem entendidos em bem definidos, e a maioria dos produtos existentes satisfazem mais de 50% do mercado em termos de funcionalidades. Isto significa que apenas uma pressão na queda dos preços, e nós observamos, recentemente, o crescimento de popularidade do MySQL e PostgreSQL, e as versões livres dos principais vendedores proprietários.

3 - Quais leituras você recomenda para aqueles que estão começando a utilizar bancos de dados?

“Database Design for Mere Mortals” e “SQL Queries for Mere Mortals” são bons para iniciar. Depois, eu sugiro ler estes livros em qualquer ordem: “PostgreSQL”, “Practical Issues in Database Design”, “SQL for Smarties” de Korry Douglas’ e, claro, não esqueça de ler a documentação do PostgreSQL.

Eu também ouvi coisas boas sobre o “SQL Cookbook” e “SQL Hacks” da O’Reily, assim como o “The Practical SQL Handbook”. Mas eu não li eles.

4 - Você foi desenvolvedor do OpenOffice.org e se tornou um desenvolvedor do PostgreSQL em 2002. O que estimulou você a trocar de projeto?

Eu me envolvi com o OpenOffice.org porque eu senti que, em 2000, era crítico para o sucesso do Código Aberto e do Linux, ter uma boa aplicação de escritório. Sem isto, as pessoas jamais poderiam trocar o Windows - incluindo eu!

Em 2002, OpenOffice.org se tornou bastante popular e teve milhões de downloads. Mas eu fui um consultor e jamais ganhei dinheiro utilizando OpenOffice.org, enquanto eu fazia muito trabalho com o PostgreSQL. Além disso, o projeto OpenOffice.org tinha muita política o que acabava afastando muitos dos voluntários. Então eu troquei de projetos.

5 - Você se tornou tesoureiro da SPI em 2006. Que tipo de relação você espera entre a SPI e o PostgreSQL?

É apenas uma forma de arrecadar fundos para nós. A SPI é atualmente apenas uma das 5 ONGs que arrecadam fundos para o PostgreSQL. As outras são o Japanese PostgreSQL Users’ Group, PostgreSQLFr.org, FFIS (Germany), e o PostgreSQL Turkey.

É claro, meu envolvimento pessoal com a SPI é muito maior que isto, mas é realmente separado do PostgreSQL.

6 - A SPI recomenda o uso de licenças livres como a GPL. Por motivos históricos o PostgreSQL adota a licença BSD. Você recomendaria outra licença para projetos como o PostgreSQL? Em quais projetos você recomendaria a adoção do conceito de copyleft?

Atualmente, eu pessoalmente prefiro a licença BSD, e não tenho a intenção de advogar a troca para o PostgreSQL.

Na minha opinião pessoal, a GPL é melhor para projetos onde o perigo de companhias se apropriarem do código sem retornar uma contribuição é significativa, e o desejo de criar um novo padrão é limitado. Licenças como o BSD (incluindo MIT e Apache) são mais apropriadas onde ter o software distribuído o máximo possível é prioritário e o projeto já tem suporte corporativo reconhecido de grandes empresas. Eu não gostaria de trocar o Linux para BSD, porque já está demonstrado o perigo de empresas derivarem e e fecharem o código.

7 - A Sun tem apoiado muito o desenvolvimento do PostgreSQL, a partir do momento que anunciou o suporte oficial. Você acha que o Solaris se tornará uma das plataformas prediletas para o PostgreSQL?

Bem, é claro que isto seria muito bom para o meu trabalho se isto ocorresse.

Num futuro imediato, eu estou apenas focando em colocar o Solaris e o OpenSolaris no mesmo passo que o Linux e o BSD dentro da comunidade do PostgreSQL. Há muito a ser feito antes que isto possa acontecer; Nós precisamos fazer versões regulares a cada 72 horas para a comunidade, há necessidade de mais documentação sobre o PostgreSQL rodando no Solaris, e mais ferramentas opcionais precisam estar disponíveis como binários para o Solaris. Finalmente, a comunidade precisa construir uma base de conhecimento sobre ajuste de performance no Solaris como a que nós temos em outros SOs.

A longo prazo, o OpenSolaris oferece algumas ferramentas e orientações de desenvolvimento que eu acredito que irão expandir o número de usuários PostgreSQL+Solaris, uma vez que nós tenhamos as coisas rotineiras acontecendo automaticamente. O DTrace, cujo suporte foi incluido no PostgreSQL 8.2, é o maior exemplo destas ferramentas; ele prove informações sobre os conflitos de bloqueios que nós não temos nenhum modo fácil de conseguir antes. Além disso, a comunidade Solaris, como a do PostgreSQL, é dedicada a segurança, estabilidade e fazem o trabalho correto e não o estritamente necessário. Desta forma, eu penso que há muitas oportunidades para uma sinergia entre os desenvolvedores do PostgreSQL e Solaris entrando em contato uns com os outros.

8 - Você acredita que ferramentas utilizadas na versão 8.2 como o DTrace devem ser adotadas em outros SOs livres como o Linux e o FreeBSD?

O DTrace já está no FreeBSD 6.2, e a Apple já estabeleceu que o fará numa versão futura do OSX. Os desenvolvedores do Linux estão trabalando numa ferramenta paralela chamada “systemtap”, e nós criamos a funcionalidade Generic Monitoring Framework no PostgreSQL 8.2 então isto irá ser compatível com o systemtap e outros frameworks de rastreamento quando elas estiverem disponíveis.

9 - Você trabalhou com o desenvolvimento do Bizgres. Em que estágio o projeto se encontra hoje e o que podemos esperar para os próximos anos?

O Bizgres é mais como um terreno de testes para funcionalidades de data warehousing para o PostgreSQL. Muitas coisas planejadas para as últimas versões do PostgreSQL estavam no Bizgres primeiro: índices bitmap-on-disk, por exemplo que vai aparecer no PostgreSQL 8.3. Eu sei que os hackers do Bizgres (a maioria da equipe da Greenplum) já estão trabalhando num gerenciador de recursos, tabelas externas anexadas, e acesso somente por índices, mas não há um calendário definido para estas coisas… ainda.

10 - Notamos que o seu site Power PostgreSQL não recebe novos artigos há algum tempo. Ao mesmo tempo, notamos que ele está de cara nova. Podemos esperar novidades nos próximos meses?

No momento em que este artigo é publicado, eu espero que todas as minhas palestras do último de conferências estejam no PowerPostgreSQL. Eu tenho blogado no ITToolBox (http://blogs.ittoolbox.com/database/soup/) ao invés do PowerPostgreSQL porque o ITToolBox me ajuda a alcançar uma maior audiência.

11- A idéia de construir um livro a partir dele continua de pé?

Bem, Joe e eu descobrimos que, após submeter os primeiros quatro capítulos, encontrar tempo para escrever um livro é muito, muito difícil. Eu estimei que para completar o livro iria requerer mais cerca 800 horas de escrita. Infelizmente, as únicas pessoas capazes de terminar o livro por nós estão ocupadas como nós, então não há um prazo de entrega a vista.

12 - O PosgreSQL tem amadurecido muito em soluções de replicação. Você acredita que num futuro próximo existirão também ferramentas de cluster para o PostgreSQL como existem para o Oracle, o BD2 ou a Teradata? Quais são as dificuldades em se implementar algo do tipo?

Bem, nós já temos um substituto para a Teradata, que é o Greenplum Database. Enquanto ele não é código aberto, é baseado no PostgreSQL e tem a sintaxe compatível. Existem soluções de consultas paralelas com menor performance já avaliáveis como o PostgresForest e Octopus.

Cluster com OLTP é um problema muito, muito difícil e nem um dos *vários* projetos de bancos de dados ou empresas conseguiram resolver este problema satisfatoriamente: nem a Oracle, nem a IBM, nem a MySQL, nem ninguém. Então, colocar qualquer tipo de data sobre quando qualquer um de nossos projetos estarão maduros para a maioria dos usuários seria muito ambicioso neste momento.

13 - Que tipo de conhecimentos um desenvolvedor do PostgreSQL deve ter?

Para hackear o PostgreSQL: algum conhecimento sobre estruturas de bancos de dados e um bom conhecimento de programação C. Para projetos adicionais no pgFoundry você pode usar a linguagem de programação que você quiser. O mais importante, você precisa ter uma certa humildade sobre o seu código e o desejo de trabalhar em uma comunidade de hackers e aprender como as coisas são feitas; um programador que achar que é mais inteligente que todo mundo não terá sucesso.

14 - Quais funcionalidades você imagina que veremos implementadas no PostgreSQL até 2012?

Eu não posso dizer o que nós teremos em 2009, deixemos 2012 em paz. O projeto se move muito, muito rápido. Nós liberamos uma versão principal todo ano e é difícil ver precisamente mais do que uma versão a frente.

Primeiro, eu gostaria de dizer algumas coisas em que eu estou trabalhando na Sun. Isto inclui uma segunda geração do pgMigrator que tornará fácil a atualização de novas versões do PostgreSQL (o pgMigrator, contribuição da EnterpriseDB, atualmente trabalha apenas com o 8.1 para o 8.2). Nós trabalhamos nisto com os programadores da Greenplum. Segundo, eu estou trabalhando em ferramentas de autoajuste/autoconfiguração que ajudarão usuários a ter uma boa performance com o PostgreSQL sem ter que ser um DBA experiente. É provável que seja um projeto de longa duração que eventualmente seja ligado ao nosso novo medidor DTrace. Finalmente, nós estamos patrocinando o trabalho de Dave Cramer na melhoria de performance do driver JDBC, onde nós temos alguns resultados realmente gratificantes.

Em médio prazo, aqui estão algumas coisas relativamente seguras que nós teremos nas próximas 3 versões ou mais, porque existem pessoas trabalhando ativamente nelas:

• Otimizações update-in-place que aumentarão a performance em OLTP entre 30% e 200%.
• Mais funcionalidades SQL99 e SQL03, como WITH RECURSIVE, RULLUP e RANK.
• Interfaces polidas para tabelas externas (possivelmente compatíveis com SQL/MED), para outros servidores/versões do PostgreSQL e para outros SGDBs.
• Tipos de dados mais exóticos, especialmente funcionalidades SQL:XML mais poderosas, e provavelmente tipos biológicos também.
• Ainda mais melhorias no otimizador de consultas.
• A eliminação do vaccuum. Eu não tenho certeza de como nós vamos falê-lo, mas nós precisamos.
• Replicação síncrona e assíncrona multi-master, de diferentes projetos.
• Publicação de benchmarks e especificações TPC.

Here is my first interview with PostgreSQL developers. I want to talk with many core developers, major developers, developer from Brazil, and developers of interesting PostgreSQL related projects. By the way this is just the first, but You could expect at least one per month.

Josh Berkus is one of the seven-member PostgreSQL Core Team, which controls releases for the PostgreSQL Project. He is also PostgreSQL Lead for Sun Microsystems, and has been a database consultant for over a decade. Josh is also a very good cook. Please note that Josh speaks only for himself and not for Sun Microsystems or the PostgreSQL project.

1 - When You start to work with computers and when You start to use FLOSS?

Oh, I started working with computers back in 1981 … with the Commodore Vic20. In high school I had an Atari 8-bit computer, and hacked the hardware extensively, as well as doing some game programming in Basic and assembler.

I started with Free Software in 1998. At the time I was a small business and non-profit consultant building database applications, and was unable to tolerate Microsoft’s rising prices and increasing number of bugs — I realized if I continued to use Microsoft, I’d go bankrupt, crazy, or both. So I switched from MS SQL Server and Visual Basic to PostgreSQL 7.0, Linux 2.2 and PHP 3. Later I picked up some Perl.

One of the clients running my first PostgreSQL application is still running it (an employment agency). One of my Microsoft platform clients is, too … but they had to hire a full-time employee to maintain the Visual Basic software.

That’s also when I got involved in the community. During the same month, I discovered bugs in both MS SQL Server 7 and PostgreSQL 7.1. My posting to comp.databases.microsoft.sqlserver was silently deleted from the MSDN forums, and the bug was never fixed. In PostgreSQL, Tom Lane (who’d joined the project only three months before) confirmed the bug within hours and provided me with an experimental patch. From then I was hooked.

2 - How do You see the market of Free and Proprietary Database?

All SQL databases will be “commoditized” within the next 10 years. That is, I expect by 2015 that there will be four kinds of databases in use: open source, shareware and freeware (like DB2 express), low-cost and specialized (like Filemaker and Pervasive), and legacy databases no longer being maintained.

This is mostly because the requirements of SQL-relational database servers are well understood and well-defined, and most existing products already satisfy more than 50% of the market in terms of features. That means that the only real competition is downward pressure on prices, and we’ve seen that a lot lately, both in the growing popularity of MySQL and PostgreSQL, and the free versions from the major proprietary vendors.

3 - With read do You recommend for those are starting to use databases?

“Database Design for Mere Mortals” and “SQL Queries for Mere Mortals” are good for just starting out. After that, I’d suggest reading these books in any order: Korry Douglas’ “PostgreSQL” “Practical Issues in Database Design” “SQL for Smarties” And, of course, don’t forget to read the PostgreSQL documentation!

I’ve also heard good things about O’Reily’s “SQL Cookbook” and “SQL Hacks”, as well as “The Practical SQL Handbook”. But I haven’t read them.

4 - You was OpenOffice.org Developer and become a PostgreSQL devel in 2002. What stimulate you to switch projects?

I got involved with OpenOffice.org because I felt that, in 2000, it was critical for the success of open source and Linux that we have good office applications. Otherwise people could never switch from Windows — including me!

By 2002, OpenOffice.org had become very popular and had millions of downloads. But I was a consultant and did not earn any money using OpenOffice.org, while I was doing a lot of PostgreSQL work. Also, OpenOffice.org project had a lot of politics which were burning out many of the volunteers. So I switched projects.

5 - You’ve become a treasurer of SPI in 2006. What kind of relation did you expect between SPI and PostgreSQL?

It’s really just a way for us to raise funds. SPI is actually only one of five non-profits which hold funds for PostgreSQL. The others are the Japanese PostgreSQL Users’ Group, PostgreSQLFr.org, FFIS (Germany), and PostgreSQL Turkey.

Of course, my personal involvement with SPI is much greater than that, but that’s really separate from PostgreSQL.

6 - SPI recommends the use of free licences like GPL. Historical reasons make PostgreSQL adopts BSD licences. Do You recommended other licence for projects like PostgreSQL? In witch projects is recommended adopt the copyleft concept?

Actually, I personally prefer the BSD license, and have no intention to advocate a change for PostgreSQL.

In my personal opinion, the GPL is best for projects where the danger of companies appropriating code without contributing back is significant, and the desire to create a new standard is limited. BSD-like licenses (including MIT and Apache) are more appropriate where getting the software distributed as far as possible is paramount, and the project already enjoys substantial loyal corporate support from large companies. I wouldn’t want Linux to switch to BSD, either, because there’s already a demonstrated danger of companies forking and closing off the code.

7 - SUN have been supporting a lot the devel of PostgreSQL. Do you think Solaris platform may become one of the preferred platform to PostgreSQL?

Well, of course it would be very good for my job if it did!

In the immediate future, I’m just shooting to put Solaris and OpenSolaris on a par with Linux and BSD in the PostgreSQL community. There’s a lot still to be done before that can happen; we need to regularly get releases out within 72 hours of the community, there needs to be more documentation on running PostgreSQL on Solaris, and more optional tools need to be available as Solaris binaries. Finally, the community needs to build up the performance tuning knowledge about Solaris that we have with other OSes.

In the longer term, OpenSolaris offers some tools and a development orientation that I believe will greatly expand the number of PostgreSQL+Solaris users once we have the routine stuff happening automatically. DTrace, with probes included in PostgreSQL 8.2, is a paramount example of these tools; it’s provided with information on lock conflicts that we didn’t have any easy way to get before. Also, the Solaris community, like PostgreSQL, is dedicated to security, sustainability, and doing the correct thing rather than just the expedient one. So I think there’s a lot of opportunity for synergy once Solaris and PostgreSQL developers get talking to each other.

8 - Do you believe that tools included in 8.2 version, like a DTrace may adopted for others free OSes, like Linux and BSD’s?

DTrace is already in FreeBSD 6.2, and Apple has stated it will make it into a future version of OSX. The Linux developers are working on a parallel utility called “systemtap”, and we created the Generic Monitoring Framework feature of PostgreSQL 8.2 so that it will be compatible with systemtap and other trace frameworks when they are available.

9 - You worked on devel of Bizgres? This project, now, find in what status and what could we expect from it in next years?

Bizgres is pretty much a testing ground for data warehousing features for PostgreSQL. A lot of stuff planned for later versions of PostgreSQL will go into Bizgres first: bitmap-on-disk indexes, for example, which will appear in PostgreSQL 8.3. I know that the Bizgres hackers (mostly Greenplum staff) are also working on resource management, external attached tables, and index-only access, but there’s no definite schedule for those things … yet.

10 - We notice that your site, “Power PostGreSQL” don’t receive any article for long time. In the same time, we notice that site have a new layout. Can we expect new features for next months?

By the time this article is published, I expect that all of my talks from the last year of conferences will be up on PowerPostgreSQL. I’m blogging on ITToolBox (http://blogs.ittoolbox.com/database/soup/) instead of on PowerPostgreSQL because ITToolBox helps me reach a wider audience.

11- the idea of write a book from this stills remain?

Well, Joe and I have both found that, after submitting the first four chapters, finding the time to write a book is very, very hard. I’d estimate that the completed book would require about 800 hours more writing. Unfortunately, the only people capable of taking over the book from us are as busy as we are, so there’s no delivery date in sight.

12 - PosgreSQL have been maturing some replication solutions. Do You believe that in a near future will be cluster tools for PostgreSQL, like in Oracle, DB2 and Teradata? Which dificulties this kind of project have?

Well, we already have a Teradata replacement, which is Greenplum Database. While it’s not open source, it is based on PostgreSQL and is syntax-compatible. There are lower-performance parallel-query solutions already available such as PostgresForest and Octopus.

OLTP clustering is a much, much harder problem and not one which *any* database project or company has solved satisfactorily: not Oracle, not IBM, not MySQL, not anybody. So putting any kind of a date on when any of our OLTP clustering projects will be suitable for a majority of users would be very ambitious at this point.

13 - What kind of knowledge a wannabe PostgreSQL developer may have?

For hacking PostgreSQL: some database design background and a good knowledge of C programming. For add-in projects on pgFoundry you can use whatever programming language you like. More importantly, you need to have some humility about your code and a desire to work with a community of hackers and learn how the project does things; a programmer who thinks that they are smarter than everyone else will not be very successful.

14 - What features You imagine we have implemented in PostgreSQL until 2012

Heck, I couldn’t tell you what we’ll have in 2009, let alone 2012. The project moves very, very fast. We do a major release every year and it’s hard to see accurately more than one release ahead, if that.

First, I can tell you some of the stuff I’m working on at Sun. This includes a second generation of pgMigrator which will make for easy update-in-place for later versions of PostgreSQL (pgMigrator, contributed by EnterpriseDB, currently handles only 8.1 to 8.2). We’re working on that with the programmers from Greenplum. Second, I’ll be working on autotuning/auto-configuration tools to help users get good PostgreSQL peformance without having to be expert DBAs. That’s liable to be a long-term project which will eventually link into our new DTrace probes. Finally, we’ve been sponsoring Dave Cramer’s work on performance improvements to the JDBC driver, which has had some really gratifying results.

In the medium run, here’s a some things I’m relatively sure we’ll get in the next three versions or so, because there’s people actively working on them:

• Update-in-place optimizations which enhance OLTP performance from 30% to 200%.
• More SQL99 and SQL03 features, like WITH RECURSIVE, ROLLUP and RANK.
• Polished external tables interfaces (possibly SQL/MED compliant), both for other PostgreSQL servers/versions and for other DBMSes.
• More exotic datatypes, especially more powerful SQL:XML features, and probably biology types as well.
• Yet more query optimizer improvements.
• The elimination of vaccuum. I’m not sure how we’re going to do it, but we must.
• Both asyncronous and syncronous multi-master replication, from different projects.
• Publication of TPC and Spec benchmarks