On Thu, 25 Aug 2005, Alvaro Herrera wrote:
> Or, slightly different, what are people's most wanted features?
Since you asked:
* concurrent, partial vacuum that would for example only scan pages that
happen to be in memory
* index-only scans
* database assertions
* lightwight PITR that wouldn't require to shut down and restore a backup.
I'm thinking something like "REWIND TO xid 12345". It could be implemented
by just setting already-committed transactions as aborted in the clog
(vacuum and commit status hint bits need to be disabled beforehand). This
would be very handy for automatic regression testing applications. You
could load the test database just once, then run test case, rewind, run
another test case, rewind and so on.
As more disruptive longer-term things:
* multiple alternative access plans for prepared statements. For example,
if you have a query like "SELECT * FROM history WHERE timestamp BETWEEN ?
AND ?", the optimal access plan depends a lot on the parameters. Postgres
could keep all the plans that are optimal for some combination of
parameters, and choose the most efficient one at execution time depending
on the parameters. The execution side would actually be quite simple to
implement. Introduce a new conditional node type that has > 1 child
nodes, and a condition that is evaluated at execution time and determines
which child node to use. Determining the conditions would require big
changes to the planner and estimation routines.
* support for Tutorial D as an alternative to SQL. It would be great for
educational purposes.
- Heikki
