с рекордом работать могут только c-функции

Так мне в функцию и надо его потом запихать

Функция то у меня будет

А, С-функции

Понял

скастуй свой row в jsonb и работай с ним

костыль на костыле

костыль на костыле

Так будто есть другие варианты?)

не зная предметной области сложно судить

Вся эта хрень нужна, чтобы из одной огромной базы можно было "вырезать" кусок данных с другой схемой и магическим образом получить консистентную базу для другого проекта на момент времени t.

Проблема в том, что сама база основного проекта не выглядит как база для домашнего веб-сайта из 3х таблиц :)

а если взять какой нить londiste3 и написать скриптов по обработке данных ? и непрерывно вытягивать ?

Так дело в том, что непрерывно не требуется.

Это нужно только тогда, когда девелоперу надо сготовить консистентный энвайромент, для стейджа, или когда что-то пошло не так при синхронизации проекта кастомера и основного проекта.

Типа убиваешь просто базу там, и льешь вот этим инструментом новую

Как бы получается, что база кастомера это такой ооогоомный кэш, который живет своей жизнью и является базой pg.

В общем, обычным CAST 'ом нельзя превратить ROW в JSON. Для этого понадобится функция row_to_json()

Спасибо за идею с JSON ?

CREATE OR REPLACE FUNCTION inheritance_get(bar __foo.bar) RETURNS text AS $$ BEGIN RETURN bar.name; END; $$ LANGUAGE plpgsql; SELECT inheritance_get(c) FROM __foo.bar c;

Внезапно. Так работает.

Всем здравствуйте =)

у меня тут тупая наверное проблемка... есть запись c text=Чердак и name=Чердак SELECT * FROM projects_project p where p."text" ILIKE '%чердак%' OR p."name" ILIKE '%чердак%' ; 0 found в чем дело?

SELECT * FROM public.journals WHERE CAST(created_on as TEXT) like '2015-12-18 09:17%'; сравни

CAST(created_on as TEXT) like '2015-12-18 09:17%'; *facepalm*

Всем здравствуйте =)

локаль?

локаль?

UTF-8

Это encoding, это не locale

CAST(created_on as TEXT) like '2015-12-18 09:17%'; *facepalm*

Зато работает. Можешь хоть до красноты себя ладошкой по лицу бить.

CAST(created_on as TEXT) like '2015-12-18 09:17%'; Жесть ))

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

Пример с явным указанием locale

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

В общем записал первое, что сработало как надо

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

а если 60 млн строк в таблице ))

вопрос про локаль это к этому http://blog.cleverelephant.ca/2016/08/pgsql-text-pattern-ops.html ?

Нет там столько)

Нет там столько)

везёт

Жесть, потому что CASE для даты зависит от локали, а date_trunc() нет.

Коллеги, подскажите, а можно ли search_path настроить так, чтобы все схемы просматривались ?

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

динамически сгенерить выражение для set search_path на основе списка всех схем %)

господа, вопрос

Коллеги, подскажите, а можно ли search_path настроить так, чтобы все схемы просматривались ?

можно альтерить search_path на уровне роли или сервера, и тогда настройку надо будет менять реже

как перемножить в постгресе два числа и не упасть?

select 1e-190::float * 1e-190::float;

как перемножить в постгресе два числа и не упасть?

со стула? :)

со стула? :)

открой консоль и попробуй сделать вышенаписанное :)

лучше на бою от пользователя postgres? :)

=> select 1e-190::float * 1e-190::float; ОШИБКА: значение вне диапазона: антипереполнение

антипереполнение!

недополнение? :)

всё так

но надо, чтобы работало :(

у меня вот так: # select 1e-190::float * 1e-190::float; ERROR: value out of range: underflow

все работает :)

Интересно, где на практике встречаются такие цифры?

ST_Distance от двух производных друг от друга геометрий

а точно нужен такой диапазон? может его можно "сдвинуть"? что-то прибавить или умножить?

меня устроит 0 в результате

просто никто, кроме постгреса, не выделывается с underflow

вот @slysha предлагает мне писать функцию на pl/python, чтобы у меня умножение работало

или округлять до нуля те значения которые меньше чем sqrt(1e-308)

ну или свой постгрес собирать :) /* 51 : : * check to see if a float4/8 val has underflowed or overflowed 52 : : */ 53 : : #define CHECKFLOATVAL(val, inf_is_valid, zero_is_valid) \ 54 : : do { \ 55 : : if (isinf(val) && !(inf_is_valid)) \ 56 : : ereport(ERROR, \ 57 : : (errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE), \ 58 : : errmsg("value out of range: overflow"))); \ 59 : : \ 60 : : if ((val) == 0.0 && !(zero_is_valid)) \ 61 : : ereport(ERROR, \ 62 : : (errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE), \ 63 : : errmsg("value out of range: underflow"))); \ 64 : : } while(0) 65 : :

ERROR: S client not available

http://pgci.eisentraut.org/jenkins/job/postgresql_master_coverage/Coverage/src/backend/utils/adt/float.c.gcov.html

а это вариант

либо юзать numeric

# select 1e-190::numeric(100, 100) ^ 2; ?column? -------------------------------------------------------------------------------------------------------- 0.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (1 строка)

numeric дальше падает по update, это ж ещё в колонку положить [local] gis@gis=# select (1e-190::numeric * 1e-190::numeric)::float; ERROR: 22003: "0.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001" is out of range for type double precision LOCATION: float8in_internal, float.c:538 Time: 0,251 ms

test=> create table test(val float); CREATE TABLE test=> insert into test values(1e-190),(1e-100); INSERT 0 2 test=> select case when val<sqrt(1e-308) then 0 else val*val end from test; case —------ 0 1e-200

test=> create table test(val float); CREATE TABLE test=> insert into test values(1e-190),(1e-100); INSERT 0 2 test=> select case when val<sqrt(1e-308) then 0 else val*val end from test; case —------ 0 1e-200

я умею писать костыли для тьюринг-полных систем. хочется добра и человечности же!

хочется

но когда не можется надо брать в руки костыли и идти вперед %)

а если раньше округлить все, что меньше 1e-189?

а если раньше округлить все, что меньше 1e-189?

а если по факту там три экрана SQL, мне в каждом умножении об этом думать? :)

мой любимый IEEE 754 говорит, что падать на underflow без особых просьб не стоит (пп. 7.5, 7.1) http://ieeexplore.ieee.org.sci-hub.cc/document/4610935/

Да.там в сорцах это явно запрашивается

#ifdef UNSAFE_FLOATS return; #else if (fabs(val) > FLOAT4_MAX) ereport(ERROR, (errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE), errmsg("type \"real\" value out of range: overflow"))); if (val != 0.0 && fabs(val) < FLOAT4_MIN) ereport(ERROR, (errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE), errmsg("type \"real\" value out of range: underflow"))); return; #endif /* UNSAFE_FLOATS */

можно еще так

select round(val::numeric*val::numeric,308)::float from test;

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

норм решение - найти галочку, которая отключает такое поведение - чтобы zero_is_valid было true

кстати

test=> select sqrt(1e-323)::float*sqrt(1e-323)::float; ?column? —--------------------- 9.88131291682493e-324 (1 row)

какбэ норм по стандарту

эксепции нет

и уж когда совсем разрядов не хватает то

test=> select sqrt(1e-324)::float*sqrt(1e-324)::float; ERROR: value out of range: underflow

а минимальная экспонента -308

15 разрядов точности как раз вот они

есть вопрос есть у меня селект, который грузит одно ядро на 95-100% и дает результат через секунд 45-50 а если 4 селекта параллельно запустить, то все 4 ядра на 95-100% и результат за 150-160 секунд postgre еще файл темповый создает на каждый запрос так вот если мне нужно работать в 50 потоков (т.е. 50 селектов одновременно), то мне нужно 51+ ядер выходит (по ядру на запрос)? или можно как-то иначе?

есть вопрос есть у меня селект, который грузит одно ядро на 95-100% и дает результат через секунд 45-50 а если 4 селекта параллельно запустить, то все 4 ядра на 95-100% и результат за 150-160 секунд postgre еще файл темповый создает на каждый запрос так вот если мне нужно работать в 50 потоков (т.е. 50 селектов одновременно), то мне нужно 51+ ядер выходит (по ядру на запрос)? или можно как-то иначе?

нужно исправить селект

там большой селект на 50кк записей в среднем (может и 100кк будет) замеры времени делались на локальной машине (i5-6400) наисправлял, раньше результат куда дольше получал если опустить момент с исправление селекта (типа уже некуда), то как поступить? я правильно мыслю по поводу ядер?

у тебя в диск может упереться, особенно если временные файлы есть

и то верно тогда нужно много озу