Re: 7.4 Wishlist

My list is;

Point to Point and Broadcast replication
----------------------------------------
With point to point you specify multiple endpoints, with broadcast you can
specify a subnet address and the updates are broadcast over that subnet.

The difference being that point to point works well for cross network
replication, or where you have a few replicants. I have multiple database
servers which could have a deadicated class C network that they are all on,
by broadcasting updates you can cutdown the amount of traffic on that net by
a factor of n minus 1 (where n is the number of servers involved).

Ability to use raw partitions
----------------------------

I've not seen an install of PostgreSQL yet that didn't put the database
files onto a filesystem, so I'm assuming it's the only way of doing it. By
using the filesystem the files are at the mercy of filesystem handler code
as to where they end up on the disk, and thus the speed of access will
always have some dependancy on the speed of the filesystem.

With a raw partition it would be possible to use two devices (e.g. /dev/hde
and /dev/hdg on an eight channel ide linux box), and PostgreSQL could then
ensure the WALs were located on one the disk with the entries running
sequentally, and that the database files were located on the other disk in
the most appropriate location (e.g. index data starting near the center of
the disk, and user table data starting near the outside).

Win32 Port
------------
I've explained the reasons before. Apart from that it's always useful to
open PostgreSQL up to a larger audience.

----- Original Message -----
From: "Daniele Orlandi" <daniele(at)orlandi(dot)com>
To: <pgsql-hackers(at)postgresql(dot)org>
Sent: Friday, November 29, 2002 11:06 PM
Subject: [mail] Re: [HACKERS] 7.4 Wishlist

> Christopher Kings-Lynne wrote:
> > Hi guys,
> >
> > Just out of interest, if someone was going to pay you to hack on
Postgres
> > for 6 months, what would you like to code for 7.4?
>
> Replication. Replication. Replication. Replication. Replication.
> Replication. Replication. Replication. Replication. Replication.
> Replication. Replication. Replication. Replication. Replication.
>
> Well, jokes apart, I think this is one of the most needed features to
> me. Currently I'm using strange voodoo to replicate some tables on other
> machines in order to spread load and resilency. Compared to what I am
> doing now a good master to slave replication would be heaven.
>
> I understand that a good replication is painful but in my experience, if
> you start by integrating some rude, experimental implementation in the
> mainstream PostgreSQL the rest will come by itself.
>
> For example, RI was something I wouldn't consider "production level" in
> 7.2, but was a start, now in 7.3 is much much better, probably complete
> in the most important parts.
>
> Other wishes (not as important as the replication issue) are:
>
> - Better granularity of security and access control, like in mysql.
>
> - Ability to reset the state of an open backend, including aborting open
> transaction to allow for better connection pooling and reusing, maybe
> giving the client the ability to switch between users...
>
> Bye!
>
> --
> Daniele Orlandi
> Planet Srl
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>