Ошибка в 6.2 + postgress

Главные вкладки

Аватар пользователя olk olk 30 мая 2008 в 15:55

Решил тут "поиграться" с 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);

Комментарии

Аватар пользователя PanDa777 PanDa777 30 мая 2008 в 16:19

А как можно было бы реализовать склейку двух строк в Postgre? Кстати, несколько странно, что это только сейчас всплыло... Неужто на Drupal так мало сайтов с pgsql? Или никто statistics не использует?

Аватар пользователя mityok mityok 1 июня 2008 в 2:13

По производительности postgres - если у хостера админ вменяемый и сделал настройку postgres "под железо", то на малых объемах данных практически не уступает mysql, на больших объемах данных - значительно выигрывает. Основная причина малой распостраненности у хостеров - для хранения базы данных требуется значительно больше дискового пространства по сравнению с MySQL, + на более ранних версиях нужно было периодически вручную запускать процедуру оптимизации базы данных, без этого значительно падала производительность.

Аватар пользователя andypost@drupal.org andypost@drupal.org 1 июня 2008 в 9:29

С настройкой он несколько сложнее mysql и на небольших объемах действительно немного отстает от последнего, но потом заметно постоянство в работе, когда у mysql начинает падать производительность значительно быстрее. Как всегда все упирается в настройку - для 6.2 пришлось делать несколько доп индексов без которых тормозило очень ощутимо. сейчас разница ощущается только при открытии страницы модулей.

Аватар пользователя PanDa777 PanDa777 30 мая 2008 в 16:58

В '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\''
);
}
?>

По-видимому, просто типы не совпадают. Как бы их преобразовать?

Аватар пользователя olk olk 30 мая 2008 в 17:29

да действительно , функция такая есть , она регистронезависимая, т.е. CONCAT в принципе потянет, но по типам аргументов она не проходит

т.е. можно определить еще одну функцию

CREATE OR REPLACE FUNCTION "concat"(int4, text)
  RETURNS text AS
SELECT CAST($1 as text) || $2  LANGUAGE 'sql' VOLATILE;

тогда можно модуль не патчить

Аватар пользователя olk olk 30 мая 2008 в 17:35

2 Stalker-g2:
Да пока и расказывать не о чем, сам второй день эту связку только щупаю,
вот поднакоплю статистики и багов, тогда расскажу Smile

Аватар пользователя olk olk 4 июня 2008 в 15:31

Еще одна ошибочка в этой же связке,

    * 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.
    * 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 Sad
буду думать !!!

Аватар пользователя KCEOH KCEOH 7 июля 2008 в 18:23

Везде где смотрел - написано что постгресс проигрывает мускулу в скорости. Единственное, что смог найти серьезное - это стабильность транзакций, у постгресса меньше шанс на левую, незавершенную транзакцию (плюс возможность объединять несколько операций в одну транзакцию), и большее соответствие ANSI SQL.

Возможно - из-за того, что документы всё старые были, 2005-2006 гг. Кто-нибудь, тыкните в более новое сравнение, хотя бы на английском.

Аватар пользователя Stalker-g2 Stalker-g2 10 июля 2008 в 23:53

Везде где смотрел - написано что постгресс проигрывает мускулу в скорости.
на мелких плохо индексированных табличках