Re: Could postgres be much cleaner if a future release skipped backward compatibility?

From: James Mansion <james(at)mansionfamily(dot)plus(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Could postgres be much cleaner if a future release skipped backward compatibility?
Date: 2009-10-25 10:27:17
Message-ID: 4AE42805.7050601@mansionfamily.plus.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Actually, I think any attempt to do that would result in a fork,
> and a consequent splintering of the community. We can get away
>
Perhaps the answer might be a pre-emptive simplifying fork to postgres-NG,
perhaps taking a lead from MySQL and Samba.

I'm not sure that you would necessarily lose too much: if the
postgres-NG system
implements a functional subset (perhaps on a subset of platforms, eg
ones with C++
and threading support) with some implementation advantages, then it
might allow
users who are interested in the potential advantages of -NG to check
that they are
using the subset while still remaining PostgreSQL users for serious use.

Suppose, for example, that you severely limit the ability of individual
connections
to load extensions, and make it a dbo task - and have an architecture
that is not
process-per-connection but process-per-db. This might allow some changes
in the
cache and read-ahead/write-behind that use large memory on modern
systems more
easily - perhaps in the way that the falcon store for MySQL planned to.
The core
query planner and execution engine can remain common, even if the process
structure that hosts it and the underlying cache page management is
quite different.

James

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Guillaume Smet 2009-10-25 10:29:34 Re: Parsing config files in a directory
Previous Message Peter Eisentraut 2009-10-25 09:08:33 Re: Parsing config files in a directory