Re: enforcing a plan (in brief)

From: Greg Stark <gsstark(at)mit(dot)edu>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: enforcing a plan (in brief)
Date: 2005-02-15 07:38:16
Message-ID: 871xbi46jb.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Neil Conway <neilc(at)samurai(dot)com> writes:

> - good, thorough documentation of the internals (naturally this would
> help attract OSS developers as well)

I don't know what software you work with but the Postgres source is far and
away the best documented source I've had the pleasure to read. I think it's
challenging to jump into because it's a legitimately complex piece of
software, not because of any deficiency in the documentation.

> - plugin APIs that make it relatively easy to replace the implementation
> of a subsystem whole-sale (if there's a cost to these APIs in terms of
> complexity or performance, it is perhaps not worth doing)

And Postgres's extensibility features like plugin languages and indexing
methods are one of its strengths.

> - APIs that allow people to drive the planner and executor
> programmatically (as in the original question)

Actually, I think that would be a neat experiment. I've often wondered about
an environment where SQL is the source language and it's compiled statically
into data structures representing plans.

But you have to be careful, it would be easy to come up with nonsensical
plans, or even plans that would be infinite loops or cause crashes.

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Kirkwood 2005-02-15 07:51:30 Re: enforcing a plan (in brief)
Previous Message Thomas Hallgren 2005-02-15 07:10:12 Re: 8.0.X and the ARC patent