-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ed L. wrote:
| On Monday November 1 2004 4:57, Justin Clift wrote:
|
|>On Mon, 2004-11-01 at 10:56 -0500, Andrew Sullivan wrote:
|>
|>
|>>A trigger on a sequence change is a terrible idea.  The whole reason
|>>sequences are transactional, &c., is to eliminate all the concurrency
|>>issues that might arise.  Adding a trigger or any other such
|>>functionality is just a recipe for concurrency costs.
|>
|>True... so what's a good way of ensuring we get an overall win here?
|>i.e. Reducing the total cost from finding the latest sequence number
|>with each sync, *more* than the overhead involved from adding some
|>mechanism to do it.
|
| Andrew is going to need to say a little more before it's clear to me
he's at
| all justified in calling sequence triggers a terrible idea.  He mistated
| the facts; sequences are NOT transactional (i.e., they're not rolled
back).
| Maybe that's just a typo on his part, I don't know.  He seems to presume
| that any sequence trigger solution must entail that they be done inside a
| transaction (thus the "concurrency costs"); I don't share that
presumption.
| If sequence values can be changed regardless of a rollback, then a
| notification regardless of rollback seems perfectly in order.  There
may be
| other reasons, but...  He asserts the concurrency costs outweigh the
| benefits, but doesn't say why those costs are required nor does he
give any
| data to support that claim, shortly after acknowledging the potentially
| significant cost on the other side of the cost-benefit ledger, polling.
| There is just a bit too much presumption here about a solution that
hasn't
| been designed.  Polling vs. asyncronous notification is a classical
| software problem, and fundamentally, that is all this is; asyncronous
| notification is the performance answer to inefficient polling.  How
exactly
| that's implemented is another question altogether.  Maybe it can't be
done
| for other reasons (too hard to code, nobody who knows how to do it
cares or
| wants to do it, etc).  But fundamentally, async notification is very
likely
| the answer to the polling inefficiencies in one form or another.

The _real_ problem is that your suggestion isn't realistic to implement.

Sequences do not presently support triggers, so adding this would
require adding that support to the database server.  That isn't going to
happen in anything resembling a short term timeframe, and it would mean
that Slony-I would become incompatible with all existing PostgreSQL
releases.  That is an absolutely unacceptable approach in that one of
the prime goals was for Slony-I to be compatible with numerous
PostgreSQL versions, including as far back as 7.3.

Some alternatives have already been mentioned:

~ 1.  For the "master" to only propagate entries when the sequence value
~     has changed

~ 2.  For there to be some "compressed encoding" of sequence updates so
~     that they are transferred and applied in more of an "en masse"
~     fashion

Neither of those ideas require changing how PostgreSQL works, so are
excellent candidates for you to try to implement.

There is plenty of room to optimize existing usage, and that is an
appropriate approach to take.  Who wants to rewrite PostgreSQL just to
support what is _claimed_ to be an optimization that we do not know is
either: a) necessary, or b) an improvement?   I sure don't.

There's little sense in talking further about "sequence triggers" or
anything that can only be supported in future versions of PostgreSQL.
It's a waste of everyone's time.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBh77BCVn6LJfHIAIRAlFTAJ90VqMbCqGsepQT/eDa7V5g7VfuVACeMQUN
vi1zPDINptTOJpq3OwGgY44=
=jjTd
-----END PGP SIGNATURE-----