Решил тут "поиграться" с postgress + drupal 6.2 и всплыла ошибочка в модуле statistics
* warning:
pg_query() [function.pg-query
]: Query failed: ERROR:
function concat
(int_unsigned, character varying
) does not exist LINE
1: SELECT
COUNT(DISTINCT
(CONCAT
(uid, hostname
))) FROM accesslog ^ HINT: No
function matches the given name and argument types. You might need to add explicit type casts. in
/var/www
/www.hotel-prog.ru/includes
/database.pgsql.inc on line
138.
* user warning: query: SELECT
COUNT(DISTINCT
(CONCAT
(uid, hostname
))) FROM accesslog in
/var/www
/www.hotel-prog.ru/modules
/statistics
/statistics.admin.inc on line
87.
В очередной раз подумалось - ну кто так пишет системные модули у смс с претензией на мультибазововсть
(ну не было ни когда в pgsql функции CONCAT !!!)
нy чтож, опять патчим :
со строки 85 в файле statistics.admin.inc
85.
$sql =
"SELECT COUNT(a.uid) AS hits, a.uid, u.name, a.hostname, SUM(a.timer) AS total, ac.aid FROM {accesslog} a LEFT JOIN {access} ac ON ac.type = 'host' AND LOWER(a.hostname) LIKE (ac.mask) LEFT JOIN {users} u ON a.uid = u.uid GROUP BY a.hostname, a.uid, u.name, ac.aid".
tablesort_sql($header);
86.
$sql_cnt =
"SELECT COUNT(DISTINCT(CONCAT(uid, hostname))) FROM {accesslog}";
87.
88.
$result =
pager_query($sql,
30,
0,
$sql_cnt);
понадеемся на то что "движок" сам почитает количество и закоменируем 86 строку, а 88 подправим
85.
$sql =
"SELECT COUNT(a.uid) AS hits, a.uid, u.name, a.hostname, SUM(a.timer) AS total, ac.aid FROM {accesslog} a LEFT JOIN {access} ac ON ac.type = 'host' AND LOWER(a.hostname) LIKE (ac.mask) LEFT JOIN {users} u ON a.uid = u.uid GROUP BY a.hostname, a.uid, u.name, ac.aid".
tablesort_sql($header);
86.
//$sql_cnt = "SELECT COUNT(DISTINCT(CONCAT(uid, hostname))) FROM {accesslog}";
87.
88.
$result =
pager_query($sql,
30,
0,
NULL);
Комментарии
А как можно было бы реализовать склейку двух строк в Postgre? Кстати, несколько странно, что это только сейчас всплыло... Неужто на Drupal так мало сайтов с pgsql? Или никто statistics не использует?
в постгрессе склека осуществлется опретором ||
'str1' || 'str2' => 'str1str2'
м
а вы не хотите рассказать побольше про опыт с pgsql, как там с производительностью?
По производительности postgres - если у хостера админ вменяемый и сделал настройку postgres "под железо", то на малых объемах данных практически не уступает mysql, на больших объемах данных - значительно выигрывает. Основная причина малой распостраненности у хостеров - для хранения базы данных требуется значительно больше дискового пространства по сравнению с MySQL, + на более ранних версиях нужно было периодически вручную запускать процедуру оптимизации базы данных, без этого значительно падала производительность.
С настройкой он несколько сложнее mysql и на небольших объемах действительно немного отстает от последнего, но потом заметно постоянство в работе, когда у mysql начинает падать производительность значительно быстрее. Как всегда все упирается в настройку - для 6.2 пришлось делать несколько доп индексов без которых тормозило очень ощутимо. сейчас разница ощущается только при открытии страницы модулей.
В 'pgsql' имена функции регистро-зависимые? При установке Drupal выполняется такой код:
<?php
if (!db_result(db_query("SELECT COUNT(*) FROM pg_proc WHERE proname = 'concat'"))) {
db_query('CREATE OR REPLACE FUNCTION "concat"(text, text) RETURNS text AS
\'SELECT $1 || $2;\'
LANGUAGE \'sql\''
);
}
?>
По-видимому, просто типы не совпадают. Как бы их преобразовать?
да действительно , функция такая есть , она регистронезависимая, т.е. CONCAT в принципе потянет, но по типам аргументов она не проходит
т.е. можно определить еще одну функцию
RETURNS text AS
SELECT CAST($1 as text) || $2 LANGUAGE 'sql' VOLATILE;
тогда можно модуль не патчить
2 Stalker-g2:
Да пока и расказывать не о чем, сам второй день эту связку только щупаю,
вот поднакоплю статистики и багов, тогда расскажу
Еще одна ошибочка в этой же связке,
* user warning: query: SELECT bx.*, bl.title FROM boxes bx INNER JOIN blocks bl ON bx.bid = bl.delta WHERE bl.module = 'block' AND bx.bid = 1 in /var/www/www.hotel-prog.ru/modules/block/block.module on line 302.
* warning: pg_query() [function.pg-query]: Query failed: ERROR: operator does not exist: integer = character varying LINE 1: ...itle FROM boxes bx INNER JOIN blocks bl ON bx.bid = bl.delta... ^ HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. in /var/www/www.hotel-prog.ru/includes/database.pgsql.inc on line 138.
* user warning: query: SELECT bx.*, bl.title FROM boxes bx INNER JOIN blocks bl ON bx.bid = bl.delta WHERE bl.module = 'block' AND bx.bid = 1 in /var/www/www.hotel-prog.ru/modules/block/block.module on line 302.
ошибка возникает при редактировании вновь созданного блока,
и опять не совместиость типов
bx.bid = bl.delta
bx.bid - integer
bl.delta - text
как победить, пока думаю, конечно проще всего проатчить block.module -> CAST(bx.bid as text) = bl.delta
но вопервых это модуль ядра,
во вторых теряется обратная совместимость с MySql
буду думать !!!
Везде где смотрел - написано что постгресс проигрывает мускулу в скорости. Единственное, что смог найти серьезное - это стабильность транзакций, у постгресса меньше шанс на левую, незавершенную транзакцию (плюс возможность объединять несколько операций в одну транзакцию), и большее соответствие ANSI SQL.
Возможно - из-за того, что документы всё старые были, 2005-2006 гг. Кто-нибудь, тыкните в более новое сравнение, хотя бы на английском.
Везде где смотрел - написано что постгресс проигрывает мускулу в скорости.
на мелких плохо индексированных табличках