Thanks for the reply. Your index is much larger than mine..so I see some
light. :)
ÓÚ 2012/3/13 14:29, Jesper Krogh дµÀ:
Our solution is to turn "fastupdate" off for our gin-indices.
http://www.postgresql.org/docs/9.0/static/sql-createindex.html
Can also be set with ALTER TABLE ALTER INDEX
I will check and try that.
I would have preferred a "backend local" batch-update process so it
could batch up everything from its own transaction instead of interferring
with other transactions.
have you tested if there is any performance boot for backend
batch-update comparing the real time updates?
I would say, that we came from Xapian and the PG-index is a way better
fit for our application. The benefits of having the fts index next to
all the
other data saves a significant amount of development time in the
application
both in terms of development and maintaince. (simpler, easier and more
manageble).
Yes, that's why I'm still looking for the improvment inside pg. This is
really a big dev/maint saver.
--
Jesper
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
