категориям не проще присвоить алиасы проиндексировать и брать без тормоза в виде ilike?

test=# create table prg(id serial, udt timestamp with time zone not null default now(), adt timestamp with time zone default '-infinity'); CREATE TABLE test=# \d prg Таблица "public.prg" Столбец | Тип | Модификаторы ---------+--------------------------+------------------------------------------- ------- id | integer | NOT NULL DEFAULT nextval('prg_id_seq'::reg class) udt | timestamp with time zone | NOT NULL DEFAULT now() adt | timestamp with time zone | DEFAULT '-infinity'::timestamp with time z one test=# insert into prg (id) values(default); INFO: analyzing "public.prg" INFO: "prg": scanned 1 of 1 pages, containing 1 live rows and 0 dead rows; 1 rows in sample, 1 estimated total rows INFO: analyze "prg" took 0.00 seconds INSERT 0 1 test=# select * from prg; id | udt | adt ----+-------------------------------+----------- 1 | 2017-04-14 13:31:57.906824+00 | -infinity (1 строка)

всем добрый вечер помогите разобраться select category from catalog where category ilike any (array['%чехлы%','%сувенир%','%подарки%','%пленки%','%детские%','%часы%']); должен же выводить все где встречаются эти слова? как сюда умудряется попасть слова вида "Смартфоны" "Телефоны и связь/Apple iPhone"

select 'Телефоны и связь/Apple iPhone' ilike any (array['%чехлы%','%сувенир%','%подарки%','%пленки%','%детские%','%часы%']); ┌──────────┐ │ ?column? │ ├──────────┤ │ f │ └──────────┘ (1 row) Time: 0,747 ms

так что очень странно

сейчас гляну спасиб

категориям не проще присвоить алиасы проиндексировать и брать без тормоза в виде ilike?

их не так много чтоб извращаться да и тормоза в виде ilike тоже не проявляются из-за кол-ва

выходит глюк постгреса

test=# create table prg(id serial, udt timestamp with time zone not null default now(), adt timestamp with time zone default '-infinity'); CREATE TABLE test=# \d prg Таблица "public.prg" Столбец | Тип | Модификаторы ---------+--------------------------+------------------------------------------- ------- id | integer | NOT NULL DEFAULT nextval('prg_id_seq'::reg class) udt | timestamp with time zone | NOT NULL DEFAULT now() adt | timestamp with time zone | DEFAULT '-infinity'::timestamp with time z one test=# insert into prg (id) values(default); INFO: analyzing "public.prg" INFO: "prg": scanned 1 of 1 pages, containing 1 live rows and 0 dead rows; 1 rows in sample, 1 estimated total rows INFO: analyze "prg" took 0.00 seconds INSERT 0 1 test=# select * from prg; id | udt | adt ----+-------------------------------+----------- 1 | 2017-04-14 13:31:57.906824+00 | -infinity (1 строка)

%ip%

iPhone

%ip%

спасибо

Спасибо большое всем за помощ. Буду пытаться понять что не так с постгресом

попробуйте полнотекстовый поиск он до слова минус окончание работает будет и точней и быстрей

Спасибо большое всем за помощ. Буду пытаться понять что не так с постгресом

с постгресом всё так, покажите запрос :)

А что за процесс исполняет commit? wal_writer или сам backend?

Ребят, а подскажите, как мне запихнуть csv в таблицу, если PostgreSQL работает в контейнере?

COPY то не видит файл

Сделать \copy from stdin?

а он поддерживает те же параметры, как и COPY на стороне сервера?

сделать \copy из клиента, запущенного вне контейнера?

пытаюсь загрузить тестовую таблицу, вот команда: COPY land_registry_price_paid_uk FROM 'pp-complete.csv' with (format csv, encoding 'win1252', header false, null '', quote '"', force_null (postcode, saon, paon, street, locality, city, district));

cat file | psql -c "COPY table FROM stdin"

а, уже вроде разобрался, спасибо)

Есть ещё \copy, которая сама файлы открывать умеет, но в итоге тот же from stdin делает...

я в итоге \copy и заюзал

Всем привет. Есть виртуальная машина, которая стоит за NAT. Пытаюсь настроить доступ к базе из вне. listen_addresses = '*' port = 5432 local all all md5 host all all 0.0.0.0/0 trust postgesql9.4, centos7 firewall-cmd —zone=public —permanent —add-port=5432/tcp Подскажите, пожалуйста, куда копать?

проброс порта снаружи через нат

проброс порта снаружи через нат

сделано

Всем привет. Есть виртуальная машина, которая стоит за NAT. Пытаюсь настроить доступ к базе из вне. listen_addresses = '*' port = 5432 local all all md5 host all all 0.0.0.0/0 trust postgesql9.4, centos7 firewall-cmd —zone=public —permanent —add-port=5432/tcp Подскажите, пожалуйста, куда копать?

Для начала покажите ифконфиг.

tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN

не нетстат, а ифконфиг

Кстати, не могу не напомнить: http://www.securitylab.ru/forum/forum23/topic42034/

не нетстат, а ифконфиг

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.88.212 netmask 255.255.255.0 broadcast 192.168.88.255 RX packets 18471 bytes 15342059 (14.6 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 9031 bytes 1103014 (1.0 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1 (Local Loopback) RX packets 1854 bytes 385929 (376.8 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1854 bytes 385929 (376.8 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

а route?

Destination Gateway Genmask Flags Metric Ref Use Iface default router 0.0.0.0 UG 100 0 0 eth0 192.168.88.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0

Ожидаемо, DNAT работать не будет

нужно либо указать шлюз с DNAT в качестве default gateway, либо настраивать на внутреннем интерфейсе шлюза не только DNAT, но и SNAT

jq? ghjcnbnt

ой, простите

router - это хостнейм шлюза?

привет всем, а такой вопрос - есть колонка varchar(15) со значениями вида '00013480', '34412424', т.е. нормальные инты, иногда дополненные слева нулями, но 7 знаков, еще там есть такие строки 'xxxxxxxxxxxx'. нужно поменять тип колонки на integer и заменить все строки, которые нельзя конвертнуть нулями. нагуглил это http://stackoverflow.com/questions/10306830/postgres-define-a-default-value-for-cast-failures сделал cast (немного упростить exception часть, потому что иначе ошибка была) create or replace function cast_to_int(text) returns integer as $$ begin -- Note the double casting to avoid infinite recursion. return cast($1::varchar as integer); exception return 0; end; $$ language plpgsql immutable; create cast (text as integer) with function cast_to_int(text); запускаю вот так ALTER TABLE table ALTER COLUMN my_column TYPE integer USING (my_column::text::integer); работает уже часов 6 на таблице в 45 млн, это нормально или можно все таки быстрее сделать?

А не проще было создать новое поле integer, проапдейтить его, повесить на старую колонку триггер чтобы не прозевать изменения, старую колонку дропнуть, а новую переименовать в старую?

вот я и не знаю, таки проще (быстрее)?

Попробуйте на тесте и так и эдак. Увидите, что быстрее.

а, табличку поменьше типа потестить, хорошая идея, спасибо

Мы обычно перед такими большими изменениями разворачиваем на тесте из бэкапа прод посвежее и тестим. На проде экспериментировать не наш метод ;)

слабаки )

cast(null to timestamp) это нормально? ничего плохого не делаю в мире?)

всем привет

Шалом

cast(null to timestamp) это нормально? ничего плохого не делаю в мире?)

null всегда null, для любого типа. IMHO конструкция смысла не имеет.

у меня почему-то просто конструкция null не работала(если быть точнее я работаю с node js драйвером pg) ибо мне надо было убрать время которое было в поле

Наверное, это особенность драйвера. test=# create table t2 (id bigint, dt timestamp); CREATE TABLE test=# insert into t2 values (11, current_timestamp ), (22, current_timestamp ); INSERT 0 2 test=# select * from t2; id | dt ----+---------------------------- 11 | 17/04/2017 12:54:58.565006 22 | 17/04/2017 12:54:58.565006 (2 rows) test=# update t2 set dt=null where id=22; UPDATE 1 test=# select * from t2; id | dt ----+---------------------------- 11 | 17/04/2017 12:54:58.565006 22 | (2 rows)

скорее всего, я тоже что-то задумался, мол а почему нельзя просто null сделать, а конкретики по ошибке нет

Обычно само проходит через некоторое время

оп, тогда пойду чай пить

База ваша в рестарт ушла.

это надолго? я что-то погуглил, достал инфу мол она будет собирать всю информацию по транзакциями за все время (или это неправда)?

Это докатка с момента последнего успешного checkpoint'а

Привет! Поделитесь, пожалуйста, впечатлениями и особенностями POWA (http://dalibo.github.io/powa/)

ERROR: S client not available

Друзья помогите стартануть pgBouncer он у меня ругается : Лог : https://pastebin.com/RJdqYDz2 Конфиг : https://pastebin.com/JhfKHmfr

pidfile = /var/run/pgbouncer/pgbouncer.pid у меня pgbouncer.pid отсутствует

unix socket is in use, cannot continue

Смотрите, что у вас с портами, куда пытается подцепиться баунсер.

netstat -ptln

tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1382/sshd tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN 3397/postgres tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1971/master tcp 0 0 0.0.0.0:6432 0.0.0.0:* LISTEN 3107/pgbouncer

он у вас уже запущен

только видимо не как сервис, а руками запускали

systemctl stop pgbouncer попробовал но он не остонавливает насколько я понимаю

@Aytuar Вы были правы ps -aux | grep pgbouncer и затем kill -9

systemctl start pgbouncer заработало

огромное спасибо всем

@alexsdag на для зачем ps? У вас в выводе netstat pid pgbouncer-а был, 3107

И я бы оченно сильно заинтересовался - чем это означенный баунсер был так занят, что к нему пришлось применять -9.

Mike Chuguniy старая привычка ps :) -9 применил просто, так как на тестовом сервере

Всем привет. У меня есть вопрос по партицированию таблиц. Вот если мы наст или партицирование и указали, например, чтобы зписи с датами до 01.01.2017 попадали в партицию 1, а записи, начиная с 01.01.2017 - в партицию номер 2. И вот мы сначала сделали вставку записи с датой 01.12.2016 - она попала в партицию 1. Что будет с записью, если мы апдейтним ее и укажем дату 01.02.2017. Она самостоятельно переместится в партицию 2 или это надо как-то менеджить?

Всем привет. У меня есть вопрос по партицированию таблиц. Вот если мы наст или партицирование и указали, например, чтобы зписи с датами до 01.01.2017 попадали в партицию 1, а записи, начиная с 01.01.2017 - в партицию номер 2. И вот мы сначала сделали вставку записи с датой 01.12.2016 - она попала в партицию 1. Что будет с записью, если мы апдейтним ее и укажем дату 01.02.2017. Она самостоятельно переместится в партицию 2 или это надо как-то менеджить?

зависит от триггеров, если есть триггер на update, то он обычно должен перенести запись.

То есть надо писать самому триггер, который удалит из одной партиции и вставит в другую?

И это надо заворачивать в транзакцию?

да, надо писать самому. Транзакционную целостность, я подозреваю, в таком случае движок обеспечит.

И это надо заворачивать в транзакцию?

нет, обычный триггер

и не надо апдейтить записи, от которых зависит партицирование

и не надо апдейтить записи, от которых зависит партицирование

добавляется триггер на update в каждую партицию

и не надо апдейтить записи, от которых зависит партицирование

Почему?

Это плохой дизайн, если у вас так происходит

ну если там пару сотен лямов, и их проапдетить, что будет?

Эт нормальный дизайн. Есть активные заказы, есть завершенные

Хм. А если не написать триггер, то запись просто обновится, останется в прежней партиции. А поиск по ней произойдет, если указывать диапазон дат?

Активные в одном партишене, завершенные в другом