Re: Could postgres be much cleaner if a future release skipped backward compatibility? - Mailing list pgsql-hackers

From James Mansion
Subject Re: Could postgres be much cleaner if a future release skipped backward compatibility?
Date
Msg-id 4AE42805.7050601@mansionfamily.plus.com
Whole thread Raw
In response to Re: Could postgres be much cleaner if a future release skipped backward compatibility?  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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



pgsql-hackers by date:

Previous
From: Guillaume Smet
Date:
Subject: Re: Parsing config files in a directory
Next
From: 노홍찬
Date:
Subject: a question about relkind of RelationData handed over to heap_update function