On Fri, 1 Jan 2010 16:19:05 -0600 Larry Garfield larry@garfieldtech.com wrote:
On Friday 01 January 2010 11:54:58 am Jean-Michel Pouré wrote:
I looked at MySQL table and they had unique indexes. This is what MySQL does: it is only a desaster. It can work for small sites, but when using large sites, you need a minimum of two servers, one for database, the other for MySQL. And you go beyond 1000 simultaneous users, you probably need a farm, which will ruin you.
Please do not spread FUD on the support list. MySQL can be an extremely effective database and very fast and scalable, if you know how to configure and maintain it properly. There are plenty of people who have such knowledge, and MySQL runs several very high-end sites. (Slashdot and, oh yeah, Drupal.org come to mind.) If you don't know how to maintain a MySQL database and try
Skype, Yahoo, Apple etc... for postgresql...
to throw something that heavy at it, sure, it's going to crumble. The same is true of any other database, or any web app, Drupal included.
I wouldn't put it this way. It's like saying that a train can take you from Hide Park to Piccadilly as well as a motorbike if you know how to drive them.
And yeah people who has been driving a motorbike for the past 5 years would oppose a bit of resistance before learning to drive a train and will hardly understand how a train can be "faster". Still a train is not a motorbike and it looks sluggish when you put it at tasks more suited for a motorbike.
Actually for few tens of a second I was thinking to use ISAM just for cache[1]... I wonder if this would become easier for D7. Yeah I'm aware of fastpath... but I still meant *easier*.
Anyway even in pure speed if you compare pg with InnoDB Postgresql became quite competitive in the past years, if you include other factors other than "pure speed" when comparing pg with InnoDB, pg is more than just competitive. So maybe you're right... other factors come to play, and not just performance. Prejudice?
'course, if you know how to maintain a Postgres database then sure, you can make it sing on low or high traffic sites. And someone who knows MySQL can do the same with MySQL. Knowing your tool matters, no matter what the tool.
Besides, what the OP asked about was how to selectively invalidate the cache to avoid running queries at all. A rant about how Postgres would be faster than MySQL really doesn't add anything to the conversation.
url were actually a very good pk for page cache (btw many urls in drupal are too short (255) including cache_page.cid). So I can't complain about having to do some extra work to invalidate the cache efficiently in my case. I was looking if I could delay a real solution to the problem passing the $expire parameter at page creation time... so that I could assign longer/shorter cache times accordingly to the probability that a certain page will become stale. But I can't see no way to pass $expire at content creation time. This seems to be true even for D7.
What is the mechanism governing "next general cache wipe"?
thanks
[1] I abandoned the idea so fast not because I thought that ISAM is not suited for anything... but just because making it works properly is not trivial and right now I don't have the time nor the need.