Markus Schiltknecht wrote: > Hi, > > Jose Orlando Pereira wrote: >> Sorry, stuff was put twice in the zip file making it somewhat >> confusing. It is in >> postgresql-g-0.1/javasrc/GordaInterfaces/docs/gapi.pdf or directly on >> the web site at http://gorda.di.uminho.pt/download/reports/gapi.pdf. > > Thank you. I've just had a quick glance at it. > >> Can you point out why is it [limiting], given that it is admittedly >> quite close? > > An API is always limiting. And if you have to change the API a lot, to > fit your needs, what's the point in using it at all? Good APIs don't > change a lot. > > Even if it's quite close, I estimate the effort to port Postgres-R to > use your API to be quite large. I.e. the first missing thing that came > to my mind was the ordering of processes when waking them up after > waiting for a lock. Postgres-R needs the processes to be woken up in > the order of writeset arrival. > > Now, I didn't see anything related in the patch, but the gapi.pdf has > 'Predictable Deadlock Handling' in it. I need to take another look... If I correctly understood your idea, a priority mechanism would be enough to do so and different applications might exploit it. Most likely, we need this to apply remote transactions. However, note that a priority mechanism is not only of interesting in the field of replication systems but it might be used to improve performance for instance.
Take a look at the ideas presented in http://www.cs.cmu.edu/~bianca/icde04.pdf Unfortunately, our current "prototype" only provides two levels: high priority or normal priority. Definitely, it should be improved and we are aware of that. > >> We'd rather discuss specific issues instead of the general topic of >> whether to build APIs around them. We certainly are not married to >> the proposed interfaces, although the functionality they capture does >> reflect our experience with several algorithms. > > I still feel that I would need ways too many hooks. Especially when > you consider advanced replication features such as data partitioning > and remote query execution. > > What also worries me is the use of triggers. ISTM that using triggers > is not deep enough in the database. In the above example, do I really > want to fire a trigger every time the database needs to wake up a > process? In PostgreSQL a trigger normally runs within a transaction. > How do you work around that? I think we are talking about different levels.... as I said a high priority mechanism would be enough. In this case, the API should provide only an interface to set the priority of a transaction.... In our case, still unfinished and quite simple: "set transaction master" but it could be easily transformed into "set transaction priority <n>". Best regards, Alfranio Junior. ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
