@Komzpa - выглядит как решение

только я на два запроса разобью - первый оценит селективность

второй уже вытащит данные либо с ранкигом либо без

зачем?

это на что-то повлияет?

чет я потерял нить рассуждений) как оценить количество доков если там лимит 100?

больше 10 секунд для john

просил explain (analyze, buffers) ибо это долго подозрительно

сейчас сделаю explain

завис :)

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

QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------------------------------- Limit (cost=63778.35..63778.60 rows=100 width=1231) (actual time=13632.699..13632.803 rows=100 loops=1) -> Sort (cost=63778.35..63825.46 rows=18843 width=1231) (actual time=13632.697..13632.744 rows=100 loops=1) Sort Key: (ts_rank(p.search, query.query, 1)) DESC Sort Method: top-N heapsort Memory: 126kB -> Nested Loop (cost=194.28..63058.18 rows=18843 width=1231) (actual time=27.701..13191.481 rows=74376 loops=1) -> Function Scan on to_tsquery query (cost=0.25..0.26 rows=1 width=32) (actual time=0.025..0.026 rows=1 loops=1) -> Bitmap Heap Scan on practitioner p (cost=194.03..62822.39 rows=18843 width=1227) (actual time=27.661..12971.466 rows=74376 loops=1) Recheck Cond: (search @@ query.query) Rows Removed by Index Recheck: 198605 Heap Blocks: exact=40567 lossy=27306 -> Bitmap Index Scan on practitioner_ts_idx (cost=0.00..189.32 rows=18843 width=0) (actual time=19.734..19.734 rows=74376 loops=1) Index Cond: (search @@ query.query) Planning time: 0.582 ms Execution time: 13633.103 ms (14 rows)

буфферы не включил)

кстати видимо статистика набралась - стало быстее :)

QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------------------------------- Limit (cost=63778.35..63778.60 rows=100 width=1231) (actual time=1286.499..1286.593 rows=100 loops=1) Buffers: shared hit=67946 -> Sort (cost=63778.35..63825.46 rows=18843 width=1231) (actual time=1286.497..1286.540 rows=100 loops=1) Sort Key: (ts_rank(p.search, query.query, 1)) DESC Sort Method: top-N heapsort Memory: 126kB Buffers: shared hit=67946 -> Nested Loop (cost=194.28..63058.18 rows=18843 width=1231) (actual time=27.777..846.612 rows=74376 loops=1) Buffers: shared hit=67946 -> Function Scan on to_tsquery query (cost=0.25..0.26 rows=1 width=32) (actual time=0.032..0.033 rows=1 loops=1) -> Bitmap Heap Scan on practitioner p (cost=194.03..62822.39 rows=18843 width=1227) (actual time=27.728..627.899 rows=74376 loops=1) Recheck Cond: (search @@ query.query) Rows Removed by Index Recheck: 198605 Heap Blocks: exact=40567 lossy=27306 Buffers: shared hit=67936 -> Bitmap Index Scan on practitioner_ts_idx (cost=0.00..189.32 rows=18843 width=0) (actual time=19.763..19.763 rows=74376 loops=1) Index Cond: (search @@ query.query) Buffers: shared hit=27 Planning time: 0.560 ms Execution time: 1286.979 ms (19 rows)

закешировалось скорее

а до этого в шаред буфферс читалось с диска

секунда больше уже похожа на правду

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

два раза подряд

а потом поставить нормальные настройки shared_buffers)

SELECT count(*) FROM "practitioner" "p", to_tsquery($TSQUERY$john$TSQUERY$) "query" WHERE "search" @@ "query" LIMIT 100; count ------- 74376 (1 row) Time: 877.708 ms

а нормальные - это что значит?

чтоб индекс помещался в него

pg_settings where name='shared_buffers'; name | setting | min_val | max_val | context ----------------+---------+---------+------------+------------ shared_buffers | 262144 | 16 | 1073741823 | postmaster (1 row)

SELECT count(*) FROM "practitioner" "p", to_tsquery($TSQUERY$john$TSQUERY$) "query" WHERE "search" @@ "query" LIMIT 100; count ------- 74376 (1 row) Time: 877.708 ms

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

я понял - просто запрос правил

это два гига?

там они в 8к страницах

что-то типа того

это чрезмерно консервативно

смотрю сорц откуда attempted to delete invisible tuple лезет - а может быть такое при краше, что один из тостов жирного тупла останется invisible, т.е. принадлежащим незавершенной трансакции, убитой крашем?

объясните пожалуйста - как выделить часть с кодом в сообщении?

три бэктика

` код `

спасибо)

только три)

что-то типа того

ставь чтоб база с индексами влезала

Стас спасибо - буду ковырятся

только три)

И только на десктопе((

Чат, вопрос простенький.

Есть запрос UPDATE table1 SET "somefield" = foo.fieldvalue FROM( SELECT id, COALESCE( CASE WHEN (table2.json_field ->> 'Imeetsya_deneg') IS NULL THEN '' ELSE (table2.json_field -> 'Imeetsya_deneg' -> 'value')::text END , '') as fieldvalue FROM table2 WHERE ...) as foo WHERE table1.value_id = foo.id;

Он выполняется, всё ок

НО как только я его хочу выполнить из триггера, обернув в EXECUTE 'Update ....' Ругается на cannot extract element from a scalar (ибо не всегда в джейсоне есть нужные мне значения)

Но для этого проверку в кейсе и писал. Вопрос: Внутри функции кейсы как-то по-другому работают?

А вообще, ну его нафиг это всё, ежу понятно что не в кейсах дело, пойду лучше пива выпью

обращайся

кавычки

кавычки

нет

Спасибо гуглу, другая проверка помогла

а можно ли как-нибудь у постгресового экстеншена дропнуть тип? :)

насколько я знаю, тип можно удалять только вместе с экстеншенем

можно, большинство эекстеншенов идут с sql который запускается при create extentions,и в нем эти типы и создаются

их и можно допнуть

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

замени операции у типа, может этого хватит

надо тип :(

можно конечно попробовать хак, удалив вхождения типа из pg_depend select * from pg_depend where objid = 657444 or refobjid = 657444; delete from pg_depend where objid = 657444 or refobjid = 657444; потом добавить oid нового типа

Чат, а как начать гуглить чтобы догуглиться о том чтобы Select только те колонки, тип которых - integer ?

я бы предположил, что сначала нужно получить список колонок с типами из таблицы и тогда уже делать запрос

получить-то получу из information_schema , а вот дальше как быть не придумаю

можно конечно попробовать хак, удалив вхождения типа из pg_depend select * from pg_depend where objid = 657444 or refobjid = 657444; delete from pg_depend where objid = 657444 or refobjid = 657444; потом добавить oid нового типа

если не добавить, ничего не умрёт? :)

не уверен ) но добавлять возможно тоже неправильно. От этого типа могут зависеть другие объекты, например функции, и они могут перестать работать. Поэтому лучше перед удалением посмотреть зависимости с помощью select * from pg_depend where refobjid = 657444; (refobjid - это oid родительского объекта в отношении зависимости)

ERROR: S client not available

получить-то получу из information_schema , а вот дальше как быть не придумаю

придумал

Es

кому то теперь будут страшные сны снится

и тёмные люди в погонах за спиной

короче странно, пробую делать`VACUUM FULL COMMENTS`, получаю: WARNING: concurrent delete in progress within table "comments" ERROR: MultiXactId 3036690260 does no longer exist -- apparent wraparound Забытых процессов постгрес нет, но есть вот эта ситуация с xmax, которых должно быть 0, тк других процессов там нет. Есть ли смысл попробовать UPDATE comments SET xmax = 0;?

Чат, вопрос.

Create table foo( "money_total" text, "101676ba" text, "cdc6889c" text );

почему поле "101676ba" в созданной таблице остается с кавычками, а поле cdc6889c - без них? В нем есть какие-то прерывающие символы (их последовательность)? А если есть, почему постгр их не обрабатывает?

почему поле "101676ba" в созданной таблице остается с кавычками, а поле cdc6889c - без них? В нем есть какие-то прерывающие символы (их последовательность)? А если есть, почему постгр их не обрабатывает?

начинается с цифры

такая же фигня если назвать поля f21d8bf4 de6aa783 d588e20d

они не с цифры начинаются

Так в том и дело

Hex?

2 разных названия, одно с цифры другео с буквы, не?

еще раз

или f21... тоже в кавычках?

тогда не понял вопросса

сделай \d на таблицу

Create table foo( "money_total" text, "cdc6889c" text ); поле мани создается с кавычками в названии, cdc6889c - без кавычек

А если заменить на апостраф или вообще без кавычек?

Откуда вообще кавычки?

В доке же на сколько я помню нет кавычек ни каких при создании таблицы

Откуда вообще кавычки?

на случай кириллических названий

Но тут же их нет

Всё равно не понимаю. ересь какая-та..\

сделай \d на таблицу

ERROR: column "reltriggers" does not exist

Create table foo( "money_total" text, "cdc6889c" text ); поле мани создается с кавычками в названии, cdc6889c - без кавычек

postgres=# Create table foo( postgres(# "money_total" text, postgres(# "cdc6889c" text ); CREATE TABLE postgres=# \d+ foo Table "public.foo" Column | Type | Modifiers | Storage | Stats target | Description -------------+------+-----------+----------+--------------+------------- money_total | text | | extended | | cdc6889c | text | | extended | | Has OIDs: no ?

...а может это просто пгадмин не так показывает..?

любое название таблицы можно заключать в кавычки