Oleg Bartunov wrote:
> what do you want to speed up ? Search is very fast, see explain analyze.
> The problem usually in the access to documents found to calculate
> rank, headlines. If GIN returns N documents, then you need to read
> all of them to calculate rank and here you get slowdown.
I don't use headline or rank yet. It's a pure test setup. The table is
around 130GB in size. The disc sub system is able to deliver around
430MB/sec sequential read, but it dies in random seek activity. To my
understanding this because of MVCC checking the visibility of each
matching row. Now I though I could improve that by moving similar rows
physically closer together. It's static data, it won't change at all.
--
Best regards,
Hannes Dorbath