Re: enforcing a plan (in brief) - Mailing list pgsql-hackers

From Greg Stark
Subject Re: enforcing a plan (in brief)
Date
Msg-id 871xbi46jb.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: enforcing a plan (in brief)  (Neil Conway <neilc@samurai.com>)
Responses Re: enforcing a plan (in brief)  (Neil Conway <neilc@samurai.com>)
List pgsql-hackers
Neil Conway <neilc@samurai.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



pgsql-hackers by date:

Previous
From: Thomas Hallgren
Date:
Subject: Re: 8.0.X and the ARC patent
Next
From: Mark Kirkwood
Date:
Subject: Re: enforcing a plan (in brief)