Слоны уже тут. Быстрые, надёжные, мощные. PostgreSQL 8.3!

Для упомянутого SELECT-a:

CREATE INDEX i_zzz ON table1 USING btree((xpath(xml_column,'//company/employee/firstname')[0]));

При том, кто есть samokhvalov, и его "всё делается легко". Видимо, по ссылочке вы бегло прочитали.

Причины: миф о легкости и лучшей производительности MySQL, за которой стоит коммерческая компания с ее рекламными бюджетами, способствует тому, что новички с их нетребовательными приложениями на нее подсаживаются, не подозревая о том, что есть лучшая альтернатива. Вот и юзают 80% малоопытных пользователей MySQL, создавая много шума по этому поводу. Оно может для них и лучше, спорить не буду, но если вы считаете, что попадаете в 20% более продвинутых, то по крайней мере необходимо осознавать, что к чему в мире СУБД. Впрочем, и для новичков, изучающих SQL, лучше начинать не с диалекта MySQL и не ACID-совместимого продукта, а с гораздо более стандартного и ACID-совместимого PostgreSQL.

Просто считаю, что не имеет сравнивать производительность плоско (одни и те же структуры данных одни и те же запросы). К этому нужно подходить более гибко, то есть ставить задачу: такой то набор данных, такая то задача по выборке и обновлению.

Описаная в тесте задача, вообщем-то не является синтетической, такого рода структуры часто встречаются. Дополнительно можно добавить индексы, но ситуацию это кардинально не исправит. Если у вас есть предложения как вот на конкретно разобранной задаче увеличить производительность, то опишите как это сделать.

После чего уже писать под каждую БД свою структуру и свои запросы, и уже тогда сравнивать производительность по скорости выполнения самой постановочной задачи.

В случае больших проектов это не имеет смысла. По сути вы можете сделать двойную работу.

PS Да MySQL может дать большую производительность при определенных условиях. Но это обычно требует дополнительных шаманств.