sendob

I don't think this is a very helpful or accurate statement. I would encourage people to actually investigate things for themselves. Generally you do trade some performance (depending upon implementation, they can be closer to the metal so to speak ) for flexibility ( again depending upon implementation ).

Consider this documentation from oracle, a very popular materialized view implementation:

"When changes are made to the master table or master materialized view using DML, an internal trigger records information about the affected rows in the materialized view log. This information includes the values of the primary key, rowid, or object id, or both, as well as the values of the other columns logged in the materialized view log. This is an internal AFTER ROW trigger that is automatically activated when you create a materialized view log for the target master table or master materialized view. "

http://mondrian.pentaho.com/ Is one I have used in the past

I agree! Geography is very valuable to some individuals; Especially with the tools available at this point, it seems strange to value being physically co-located for work.

I agree, I don't think this reflects well on the postgres community( in so far that Heroku is a member of that community ).

Heroku has certainly done a lot to demonstrate how effective postgres can be practice, in addition to other contributions ).

All that being said, we don't actually know what the fix looks like, or indeed what their code looks like either right? For all we know this could be being pushed upstream? It could in some other way be unsuitable for general consumption/adoption at this time. It is possible that the fact that Heroku is going to burn it in will end up uncovering an issue or some other fact that will benefit the project, or they may be uniquely "extra" vulnerable because of deviations.

The PostgreSQL license cuts(so to speak) both ways in this case: http://www.postgresql.org/about/licence/

Heroku has things like: https://postgres.heroku.com/fork

they are a database as a service, not a distributor of software.

you are good to be suspicious into any benchmark(as even the original slides note). I dont think we really have any information as it relates to transaction boundaries present, nor clients used:

From the slides: "Scripts read a CSV file, parse it into the appropriate format, INSERT it into the database. • We measure total load time, including parsing time. • (COPY will be much much much faster.) • mongoimport too, most likely."

Postgres does its best to use intelligent defaults, but it is only a part of the system, it is generally up to practioners to be wary. Tools like: http://www.postgresql.org/docs/current/static/pgtestfsync.ht... Assist in this goal, but generally have to watch out for things like raid controllers that are not battery backed etc ( depending upon your environment).

There is no mention of the number of clients used directly.

I was simply trying to highlight that with the (little) information available, it is very possible.

It is also possible, that the session(s) should themselves choose to pursue an asynchronous commit strategy ( on a session level see:http://www.postgresql.org/docs/9.2/static/wal-async-commit.h... ) which would also not require modifying the configuration, I do not know as I have not seen the scripts, but it is similar to how a library could interact with:

http://docs.mongodb.org/manual/reference/command/getLastErro...

Thanks.

from the link: "In Postgres 9.2, this improvement automatically becomes available without any further configuration."

"Essentially, it accomplishes this by reducing the lock contention surrounding an internal lock called WALWriteLock. When an individual backend/connection holds this lock, it is empowered to write WAL into wal_buffers, an area of shared memory that temporarily holds WAL until it is written, and ultimately flushed to persistent storage."

"With this patch, we don’t have the backends queue up for the WALWriteLock to write their WAL as before. Rather, they either immediately obtain the WALWriteLock, or else queue up for it. However, when the lock becomes available, no waiting backend actually immediately acquires the lock. Rather, each backend once again checks if WAL has been flushed up to the LSN that the transaction being committed needs to be flushed up to. Oftentimes, they will find that this has happened, and will be able to simply fastpath out of the function that ensures that WAL is flushed (a call to that function is required to honour transactional semantics). In fact, it is expected that only a small minority of backends (one at a time, dubbed “the leader”) will actually ever go through with flushing WAL. In this manner, we batch commits, resulting in a really large increase in throughput..."

I am sorry to cut and paste so much of the article, but I hope this is helpful?

that post, also discusses using a 7200rpm disk.

I think where you may be confused is considering them as distinct IO operations, vs seeing it as a point which must have been flushed past ( sequentially )

http://pgeoghegan.blogspot.com/2012/06/towards-14000-write-t... may interest you