On Apr 19, 2005, at 22:56, Dann Corbit wrote:
Have you actually seen any problem in simple get/put/delete/update situations?
Not sure, that I understand your question.
It's a shame when people spend a great deal of effort to invent a cure for a disease that does not exist.
If you have problems with any of these things, there are usually good solutions.
Not always. Please, keep in mind, that not all problems need so complicated querys.
Using the copy API, you can insert like a raving madman. PostgreSQL has
a prepared insert.
Yes, but it will be rest "prepared" till the end of the session.
Safe, transacted inserts will be hard to do much faster than that.
INSERT is not the main problem, SELECT - is. Why I need complicated SELECT * FROM words WHERE id = 21 to just make simple key/value search?
You can also bracket bunches of operations in a single transaction if you like. In real life, how fast can you update records? If you have a titanic pile of users all trying to update, then the MVCC model is probably close to optimal anyway.
Again, INSERT and UPDATE is not a main problem.
Do you have some measurement that shows PostgreSQL is not performing up to a real business case time requirement?
And again, business can be different.
Sometimes, we can be guilty of 1980's batch oriented mind-set, if we have been doing data processing for a long time. The old paradigms no longer apply for the most part.
Recommended reading:
http://research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR- TR-2
005-39
Thank you for the reading, but it is not the case for me.
First of all, I will repeat, in some situations, you need not so complicated solution, and nothing comes for free. In some situation you may need faster access with more complicated API, in some, of course, SQL is more suitable.
As Tom said absolutely correct, in such situations Berkeley DB is something that more suitable, but it will add another one database, so ISAM-like (native, which does not translate it's calls to the SQL) access to the PostgreSQL will be just fine.
Regards, /Alexandre.
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
