At 12:23 PM +0100 1999-12-27, Chris M¸ller wrote:
>Thanks, Paul, for the interesting and competent answer.
>I am planning on upgrading to 3.23.7 to take advantage of the TEMPORARY
>table and the HEAP options.
>One thing that still puzzles me:
>I have also tried to process my 10 searches using a script and sending
>individual SELECT statements (without OR)from the comman line. The
>result is the same as with the ORs, i.e. it took the batch file not 10
>times the 0.2 secs, but just about the same time as the single SELECT
>with the ORs (more than one minute).
Do each of the individual searches come in at 0.2 seconds, or is there
some particular term or terms that take a long time to search for?
>My concern ist that if I call the 10 searches from my application
>(minivend shopping cart), it will also be processed like a batch and
>take as long. Minivend is using Perl DBI.
>Therefore, the proposed temporary table seems like the best option. I
>hope that minivend will be able to cope with it.
>
>Thanks again. Your input has certainly been very valuable and helpful to
>me.
>
>Chris
>
>
>Paul DuBois wrote:
>>
>>
>> If you read in the manual how indexes are used, you will also find that
>> OR-ing together conditions prevents indexes from being used efficiently.
>> You'll probably get better results by running several independent queries,
>> each of which searches for one of the terms that you're OR-ing together.
>> If you want to present the results all at once or in a particular order,
>> you can retrieve them into a temporary table, then select from that table.
>> This will also allow you to eliminate duplicates in the result.
>>
>> >
>> >I would greatly appreciate any hints to help me solve this mistery.
>> >
>> >Another question:
>> >My search results are presented via the rather slow Internet. I notice
>> >that the search results are only presented when the search is completed.
>> >Is there a way to force mySQL to spill-out the results gradually, i.e.
>> >as they are being built. The idea is to start transmitting as soon as
>> >possible, even if the search is not completed, since transmission will
>> >last longer than the time to complete the search. This could shorten the
>> >time from dispatching the search to its presentation on the Browser.
>>
>> This depends on whether your search interface allows you to specify
>> that the query should use mysql_use_result() rather than
>>mysql_store_result()
>> to return the results. DBI will, for example, but PHP will not. However,
>> if you decide to use multiple independent queries (as outlined above),
>> this won't do you any good -- but that may not matter because your
>>performance
>> will be increased.
--
Paul DuBois, paul@stripped
