[sisyphus] postgresql index row

[sisyphus] postgresql index row

[Igor Zubkov]

Hi!

Никто не сталкивался вот с таким?

==  AddIndexOnChangelogtext: migrating ========================================
-- add_index(:changelogs, :changelogtext)
rake aborted!
An error has occurred, this and all later migrations canceled:

PGError: ERROR:  index row requires 10744 bytes, maximum size is 8191
: CREATE  INDEX "index_changelogs_on_changelogtext" ON "changelogs"
("changelogtext")

(See full trace by running task with --trace)

-- 
Igor Zubkov
http://hi.im/ice

Re: [sisyphus] postgresql index row

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

On Fri, Nov 12, 2010 at 04:05:03AM +0200, Igor Zubkov wrote:
> ==  AddIndexOnChangelogtext: migrating ========================================
> -- add_index(:changelogs, :changelogtext)
Занахрена?

-- 
Regards,    --
Sir Raorn.   --- http://thousandsofhate.blogspot.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [sisyphus] postgresql index row

[Igor Zubkov]

2010/11/12 Alexey I. Froloff:
> On Fri, Nov 12, 2010 at 04:05:03AM +0200, Igor Zubkov wrote:
>> ==  AddIndexOnChangelogtext: migrating ========================================
>> -- add_index(:changelogs, :changelogtext)
> Занахрена?

Вот что бы такой запрос к БД работал быстро, а не как сейчас...
ree-1.8.7-2010.02 > Changelog.where('changelogtext LIKE \'%CVE%\'').count
 => 4288
ree-1.8.7-2010.02 >

2010/11/12 Ivan Fedorov:
> Igor Zubkov writes:
>> Hi!
>>
>> Никто не сталкивался вот с таким?
>>
>> ==  AddIndexOnChangelogtext: migrating ========================================
>> -- add_index(:changelogs, :changelogtext)
> Ну во первых и впрямь, "а нахрена?!".

Для быстрого поиска.

> А во вторых оно всё равно не будет хорошо работать. Если вам нужен поиск
> по тексту - то надо пользоваться FTS движками. В PostgreSQL например
> встроен tsearch2. Из отдельных - Sphinx весьма неплох, да и настроить не
> имея опыта его проще чем tsearch2.

Ммм... А Sphinx умеет правильно работать с бинарными полями? Просто
это самое поле ещё и BINARY в postgresql у меня.

> А обычные btree индексы нормально искать по тексту всё равно не
> позволят. А если нужна проверка на уникальность, то там и индекса от
> какого-нить хэша хватит.

2010/11/12 Денис Смирнов:
> On Fri, Nov 12, 2010 at 04:05:03AM +0200, Igor Zubkov wrote:
>
> IZ> Никто не сталкивался вот с таким?
>
> А есть хоть какой-то смысл от _индекса_ по полю немеряного размера?

Понятия не имею. :)

> Даже если бы это работало -- это было бы все равно ужасно. Опиши какую
> задачу ты хочешь решить этим странным действием, и тогда тебе подскажут
> как ее решить красиво.

Дано много-примного записей из changelog'ов пакетов. Примерно:
ree-1.8.7-2010.02 >   Changelog.count(:all)
 => 690859
ree-1.8.7-2010.02 >
Столько :)

Охота вытаскивать из этой кучи только те в которых есть упоминание о
CVE. Без индекса это просто медленно. Индекс не делается.

Вот думаю, а не воткнуть ли туда sphinx? Или как бы ещё решить такую задачку.

-- 
Igor Zubkov
http://hi.im/ice

Re: [sisyphus] postgresql index row

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

On Fri, Nov 12, 2010 at 06:06:59PM +0200, Igor Zubkov wrote:
> >> ==  AddIndexOnChangelogtext: migrating ========================================
> >> -- add_index(:changelogs, :changelogtext)
> > Занахрена?
> Вот что бы такой запрос к БД работал быстро, а не как сейчас...
> ree-1.8.7-2010.02 > Changelog.where('changelogtext LIKE \'%CVE%\'').count
>  => 4288
> ree-1.8.7-2010.02 >
"Шарик, ты балбес!" (ц)

http://www.postgresql.org/docs/9.0/interactive/indexes-types.html

"""The optimizer can also use a B-tree index for queries
involving the pattern matching operators LIKE and ~ *if* the
pattern is a constant and is anchored to the beginning of the
string -- for example, col LIKE 'foo%' or col ~ '^foo', but
not col LIKE '%bar'."""

-- 
Regards,    --
Sir Raorn.   --- http://thousandsofhate.blogspot.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [sisyphus] postgresql index row

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

On Fri, Nov 12, 2010 at 07:25:42PM +0300, Alexey I. Froloff wrote:

AIF> "Шарик, ты балбес!" (ц)
AIF> http://www.postgresql.org/docs/9.0/interactive/indexes-types.html
AIF> """The optimizer can also use a B-tree index for queries
AIF> involving the pattern matching operators LIKE and ~ *if* the
AIF> pattern is a constant and is anchored to the beginning of the
AIF> string -- for example, col LIKE 'foo%' or col ~ '^foo', but
AIF> not col LIKE '%bar'."""

Добавлю -- если понимать как работает b-tree индекс, то становится
очевидным что работать иначе оно не может.

Ибо он помогает только для операций сравнения. При этом x like 'abc%' это
то же самое что: (x >= 'abc' AND x < 'abd'), и только поэтому индекс
помогает в этой ситуации искать.

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

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [sisyphus] postgresql index row

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 2122 bytes --]

On Fri, Nov 12, 2010 at 06:06:59PM +0200, Igor Zubkov wrote:

IZ> Вот что бы такой запрос к БД работал быстро, а не как сейчас...
IZ> ree-1.8.7-2010.02 > Changelog.where('changelogtext LIKE \'%CVE%\'').count
IZ>  => 4288
IZ> ree-1.8.7-2010.02 >

Он не будет работать быстрее. Ибо индексы помогают только для поиска
_префикса_. LIKE 'ABC%' -- использует индексы, а LIKE '%CVE%' -- увы, не
испоьлзуют.

IZ>>> ==  AddIndexOnChangelogtext: migrating ========================================
IZ>>> -- add_index(:changelogs, :changelogtext)
IZ>> Ну во первых и впрямь, "а нахрена?!".
IZ> Для быстрого поиска.

Индесы это не просто "штука чтобы искать все было быстрее". Если бы было
так -- просто создавали бы индексы на все колонки и радовались бы жизни :)

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

>> Даже если бы это работало -- это было бы все равно ужасно. Опиши какую
>> задачу ты хочешь решить этим странным действием, и тогда тебе подскажут
>> как ее решить красиво.
IZ> Дано много-примного записей из changelog'ов пакетов. Примерно:
IZ> ree-1.8.7-2010.02 >   Changelog.count(:all)
IZ>  => 690859
IZ> ree-1.8.7-2010.02 >
IZ> Столько :)
IZ> Охота вытаскивать из этой кучи только те в которых есть упоминание о
IZ> CVE. Без индекса это просто медленно. Индекс не делается.
IZ> Вот думаю, а не воткнуть ли туда sphinx? Или как бы ещё решить такую задачку.

На этапе импортирования %chanelog в базу вытаскивать эти самые CVE. И
класть в отдельную табличку с полями -- CVE,package,version

к ней два индекса -- один по CVE, другой по паре package,version.

version, разумеется, не в смысле %version, а полностью -- включая serial и
release.

Если нам приходится часто выполнять какой-то сложный запрос -- его не надо
оптимизировать. Надо его ликвидировать, а предварительно заготовленный
результат держать в отдельной табличке.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [sisyphus] postgresql index row

[Alex Gorbachenko]

[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]

On Fri, 12 Nov 2010 19:39:23 +0300
Денис wrote:

>На этапе импортирования %chanelog в базу вытаскивать эти самые CVE. И
>класть в отдельную табличку с полями -- CVE,package,version

строго говоря, лучше три таблички. id(PK),package_name -<
id(PK),)(package_id,package_version)UNIQUE) -< id(PK),((name_version_id,
CVE)UNIQUE). индексы очевидны.

join в данном случае дешёвый.

>Если нам приходится часто выполнять какой-то сложный запрос -- его не
>надо оптимизировать. Надо его ликвидировать, а предварительно
>заготовленный результат держать в отдельной табличке.

и это правильно, но tsearch2 всё равно придётся осилить для поиска по
описаниям пакетов и тем же спискам изменений. осиливать там ровно 2
страницы текста.

-- 
np: IRON MAIDEN - Satellite 15... The Final Frontier

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [sisyphus] postgresql index row

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

On Sat, Nov 13, 2010 at 09:23:10AM +0300, Alex Gorbachenko wrote:

AG> строго говоря, лучше три таблички. id(PK),package_name -<
AG> id(PK),)(package_id,package_version)UNIQUE) -< id(PK),((name_version_id,
AG> CVE)UNIQUE). индексы очевидны.
AG> join в данном случае дешёвый.

Если для package_name использовать hash-index'ы, то если я правильно понимаю --
этот вариант будет даже чуточку медленнее.

AG> и это правильно, но tsearch2 всё равно придётся осилить для поиска по
AG> описаниям пакетов и тем же спискам изменений. осиливать там ровно 2
AG> страницы текста.

Это да. Кстати я пока так и не осилил :)

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [sisyphus] postgresql index row

[Ivan Fedorov]

[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]

Alex Gorbachenko <agent_007-9UoSgsGcav8@public.gmane.org> writes:

>>Если нам приходится часто выполнять какой-то сложный запрос -- его не
>>надо оптимизировать. Надо его ликвидировать, а предварительно
>>заготовленный результат держать в отдельной табличке.
>
> и это правильно, но tsearch2 всё равно придётся осилить для поиска по
> описаниям пакетов и тем же спискам изменений. осиливать там ровно 2
> страницы текста.

Ну это вы весьма погорячились, я не зря сказал, что Sphinx получается
проще, правильная настройка tsearch2 - тот ещё гемор.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] postgresql index row

[Ivan Fedorov]

[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]

Igor Zubkov <igor.zubkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
writes:

> Hi!
>
> Никто не сталкивался вот с таким?
>
> ==  AddIndexOnChangelogtext: migrating ========================================
> -- add_index(:changelogs, :changelogtext)
Ну во первых и впрямь, "а нахрена?!".

А во вторых оно всё равно не будет хорошо работать. Если вам нужен поиск
по тексту - то надо пользоваться FTS движками. В PostgreSQL например
встроен tsearch2. Из отдельных - Sphinx весьма неплох, да и настроить не
имея опыта его проще чем tsearch2.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] postgresql index row

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

On Fri, Nov 12, 2010 at 04:05:03AM +0200, Igor Zubkov wrote:

IZ> Никто не сталкивался вот с таким?

А есть хоть какой-то смысл от _индекса_ по полю немеряного размера?

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

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[sisyphus] [JT] Re: postgresql index row

[Ivan Fedorov]

[-- Attachment #1: Type: text/plain, Size: 517 bytes --]

"Денис Смирнов" <mithraen-EzvwY9xUkZCGiqJ2EaRE8Q@public.gmane.org>
writes:

> On Fri, Nov 12, 2010 at 04:05:03AM +0200, Igor Zubkov wrote:
>
> IZ> Никто не сталкивался вот с таким?
>
> А есть хоть какой-то смысл от _индекса_ по полю немеряного размера?

Есть - его удалением можно круто ускорить работу базы, и взять за это
немерянно бабла! :-D

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] [JT] Re: postgresql index row

[REAL]

12.11.2010 18:25, Ivan Fedorov пишет:
>> А есть хоть какой-то смысл от _индекса_ по полю немеряного размера?
>
> Есть - его удалением можно круто ускорить работу базы, и взять за это
> немерянно бабла! :-D

Такое в анналы просится :)

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ