entwicklungsgedanken » Search

Allowing PostgreSQL to use an index when the query uses the LIKE-operator

Eric Bartels — Wed, 05 Aug 2009 18:31:14 +0000

When enabling search in database its very important to have the appropriate indexes defined to make the queries as fast as possible. If your query looks like this (and the appropriate index is defined) the index can be used by the database (the query planner) even with the LIKE-operator. So fast wildcard-searches are possible …

SELECT col1 FROM foobar WHERE col1 LIKE '1234%';

Yes?! Really?!

In one of our production systems this kind of query (when debugged via EXPLAIN / EXPLAIN ANALYZE) return unexpected results. Every time our comparison operator turns from equality = into LIKE the index for the column is fully ignored and instead a full-table scan (sequential scan) is used by the planner. Things are really slow …

I locale you!

After asking Google its seems some more people having this issue, too.
Our database-cluster was initialized with the locale de_DE.utf8. A quick view into the excellent documentation for CREATE INDEX revealed there is an operator class which controls the operators of the index. After adding an index with an operator class for that column the index (“FoobarWildcardIdx”) is now used even when the query contains LIKE.

CREATE INDEX FoobarWildcardIdx ON foobar (col1 varchar_pattern_ops);

One reason for: “The crawler could not communicate with the server. Check that the server is available and that the firewall access is configured correctly..”

Eric Bartels — Fri, 17 Jul 2009 02:38:19 +0000

Today the crawler of the search service of my MOSS-Development system stopped working from “one second to another”. The crawl-log showed me this error.
The crawler could not communicate with the server. Check that the server is available and that the firewall access is configured correctly..

The start is essential

I reconfigured everything, I checked the database-security, rebooted the virtual machine, re-created the content-sources. Nothing helped …

After some digging I found out that the start page of that site-collection (default.aspx) throws an exception due to a faulty web part…
This can’t be… Can it?! I removed the faulty web part from the default.aspx and the start page runs normal … and so does the crawler!

Because of an erroneous start page the whole crawling process for that site-collection is not working!

Conclusion

Make sure that the “entrance” to your site-collections is wide open and totally working …

PS: Excluding the default.aspx via “Crawl rules” does not work. The crawler still stops.

System.ServiceProcess.TimeoutException when running psconfig

Eric Bartels — Fri, 18 Jul 2008 07:36:06 +0000

Today I was installing a hotfix from Microsoft to get rid of an error. After installing one had to run the SharePoint Products and Technologies Configuration Wizard (psconfig) to complete the installation and update the database-schema.

This failed with the following error.

Failed to initialize SharePoint Products and Technologies upgrade.
An exception of type System.ServiceProcess.TimeoutException was thrown.  Additional exception information: Time out has expired and the operation has not been completed.
System.ServiceProcess.TimeoutException: Time out has expired and the operation has not been completed.
   at System.ServiceProcess.ServiceController.WaitForStatus(ServiceControllerStatus desiredStatus, TimeSpan timeout)
   at Microsoft.SharePoint.PostSetupConfiguration.ServiceHelper.Stop(String serviceName)
   at Microsoft.SharePoint.PostSetupConfiguration.InitializeTask.StopServicesListedInRegistry(RegistryHelper registry)
   at Microsoft.SharePoint.PostSetupConfiguration.InitializeTask.StopAllServices()
   at Microsoft.SharePoint.PostSetupConfiguration.InitializeTask.PrepareForUpgrade()
   at Microsoft.SharePoint.PostSetupConfiguration.InitializeTask.Run()
   at Microsoft.SharePoint.PostSetupConfiguration.TaskThread.ExecuteTask()

I feared that the hotfix was erroneous … But that was not the case. The Office SharePoint Server Search Service simply had a freeze and was gone away. Manually killing the process (mssearch.exe) helped here.

Running the SharePoint Products and Technologies Configuration Wizard again was now successful and the hotfix was installed.