Ron Mayer wrote: > Bruce Momjian wrote: > > Oleg Bartunov wrote: > >> What is a basis of your assumption ? In my opinion, it's very limited > >> use of text search, because it doesn't supports ranking. For 4-5 years > >> of tsearch2 usage I never used it and I never seem in mailing lists. > >> This is very user-oriented feature and we could probably ask > >> -general people for their opinion. > > I think I asked about this kind of usage a couple years back; > and Oleg pointed out other reasons why it wasn't as good an > idea too. > > http://archives.postgresql.org/pgsql-general/2005-10/msg00475.php > http://archives.postgresql.org/pgsql-general/2005-10/msg00477.php > > The particular question I had asked why the functional index was > slower than maintaining the extra column; with the explanation > that the lossy index having to call the function (including > parsing, dictionary lookup, etc) for re-checking the data made > it inadvisable to avoid the extra column anyway. > > > I doubt 'general' is going to understand the details of merging this > > into the backend. I assume we have enough people on hackers to decide > > this. > > > > Are you saying the majority of users have a separate column with a > > trigger? > > I think so. At least when I was using it in 2005 the second > column with the trigger was faster than using a functional index.
OK, it is good you measured it. I wonder how GIN would behave because it is not lossy. > >> We need more feedback from users. > > > > Well, I am waiting for other hackers to get involved, but if they don't, > > I have to evaluate it myself on the email lists. > > Personally, I think documentation changes would be an OK way to > to handle it. Something that makes it extremely clear to the > user the advantages of having the extra column and the risks > of avoiding them. Sure, but you have make sure you use the right configuration in the trigger, no? Does the tsquery have to use the same configuration? -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
