Re: Could postgres be much cleaner if a future release skipped backward compatibility?
От | James Mansion |
---|---|
Тема | Re: Could postgres be much cleaner if a future release skipped backward compatibility? |
Дата | |
Msg-id | 4AE42805.7050601@mansionfamily.plus.com обсуждение исходный текст |
Ответ на | Re: Could postgres be much cleaner if a future release skipped backward compatibility? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: