Following on from Volker's question about the forum running slow which seems to have been fixed, searching seems to have gone from slowish to not working. After about a minute I get a 500 error and a picture of a cute kitten:

cute kitten

which, while nice, isn't particularly helpful :) Selecting by tag is fine, it seems to be the free text searching that isn't playing.

asked 02 Apr '14, 13:19

Justin%20Willey's gravatar image

Justin Willey
6.7k108141208
accept rate: 20%

edited 02 Apr '14, 14:15

Comment Text Removed

And now it is the 7th. This forum has been not working for almost a week now.

(07 Apr '14, 16:52) rickrat
Replies hidden

Hmmm, we're not sure what has changed that has caused searching to fail. I've tried a few searches: some work, some timeout. ?

We are continuing to look into this problem. I'll post back here when we figure it out.

(07 Apr '14, 17:59) Mark Culp

That's what I'm seeing too, no obvious pattern; however no searches are quick.

(08 Apr '14, 18:47) Justin Willey

Please forgive the lateness of my reply, but this should be fixed now. Searches on the forum still use the SQL Anywhere full-text search mechanism, but the query itself has been fixed so that the optimizer can do clever things with it. As a result, queries are much faster than before (i.e. the search mechanism is now usable).

permanent link

answered 07 Jul '14, 13:54

Graeme%20Perrow's gravatar image

Graeme Perrow
8.5k371109
accept rate: 52%

1

> the search mechanism is now usable

A bold claim which appears to be true!

> the query itself has been fixed so that the optimizer can do clever things with it.

This being a forum about SQL Anywhere, it seems only reasonable that you share the details! Please!

(07 Jul '14, 15:16) Breck Carter
Replies hidden
4

To do the full-text search, we created a view that had the CONTAINS clause and ranking stuff in it, and then told Django to join that view to the query it was running. But the query that resulted had several layers of subselects, and the join with the view was in one of the subselects. This caused the optimizer some headaches because of the full-text search and so it made what we'll call suboptimal choices. We fixed this by creating a local temporary table and doing an insert into local_temp select * from myview. Then we joined the temporary table instead of the view to Django's query, and this made the optimizer much happier.

(07 Jul '14, 20:16) Graeme Perrow
2

and this made the optimizer much happier.

Us, too:)

(08 Jul '14, 06:22) Volker Barth
2

Wow - what an improvement! Many thanks Graeme.

(09 Jul '14, 02:58) Justin Willey
1

I've been used to rely on tags for searching, but now full text search isn't just working, it's surprisingly fast. Awesome!

(21 Jul '14, 07:59) Reimer Pods
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×164

question asked: 02 Apr '14, 13:19

question was seen: 1,473 times

last updated: 21 Jul '14, 07:59