General query settings¶
SetSelect¶
Prototype: function SetSelect ( $clause )
Sets the select clause, listing specific attributes to fetch, and Sorting modes to compute and fetch. Clause syntax mimics SQL.
SetSelect() is very similar to the part of a typical SQL query between SELECT and FROM. It lets you choose what attributes (columns) to fetch, and also what expressions over the columns to compute and fetch. A certain difference from SQL is that expressions must always be aliased to a correct identifier (consisting of letters and digits) using ‘AS’ keyword. SQL also lets you do that but does not require to. Manticore enforces aliases so that the computation results can always be returned under a “normal” name in the result set, used in other clauses, etc.
Everything else is basically identical to SQL. Star (‘*’) is supported. Functions are supported. Arbitrary amount of expressions is supported. Computed expressions can be used for sorting, filtering, and grouping, just as the regular attributes.
When using GROUP BY agregate functions (AVG(), MIN(), MAX(), SUM()) are supported.
Expression sorting (Sorting modes) and geodistance functions (SetGeoAnchor) are now internally implemented using this computed expressions mechanism, using magic names ‘@expr’ and ‘@geodist’ respectively.
Example:
$cl->SetSelect ( "*, @weight+(user_karma+ln(pageviews))*0.1 AS myweight" );
$cl->SetSelect ( "exp_years, salary_gbp*{$gbp_usd_rate} AS salary_usd,
IF(age>40,1,0) AS over40" );
$cl->SetSelect ( "*, AVG(price) AS avgprice" );
SetLimits¶
Prototype: function SetLimits ( $offset, $limit, $max_matches=1000, $cutoff=0 )
Sets offset into server-side result set ($offset
) and amount of
matches to return to client starting from that offset ($limit
). Can
additionally control maximum server-side result set size for current
query ($max_matches
) and the threshold amount of matches to stop
searching at ($cutoff
). All parameters must be non-negative
integers.
First two parameters to SetLimits() are identical in behavior to MySQL
LIMIT clause. They instruct searchd
to return at most $limit
matches starting from match number $offset
. The default offset and
limit settings are 0 and 20, that is, to return first 20 matches.
max_matches
setting controls how much matches searchd
will keep
in RAM while searching. All matching documents will be normally
processed, ranked, filtered, and sorted even if max_matches
is set
to 1. But only best N documents are stored in memory at any given moment
for performance and RAM usage reasons, and this setting controls that N.
Note that there are two places where max_matches
limit is
enforced. Per-query limit is controlled by this API call, but there also
is per-server limit controlled by max_matches
setting in the config
file. To prevent RAM usage abuse, server will not allow to set per-query
limit higher than the per-server limit.
You can’t retrieve more than max_matches
matches to the client
application. The default limit is set to 1000. Normally, you must not
have to go over this limit. One thousand records is enough to present to
the end user. And if you’re thinking about pulling the results to
application for further sorting or filtering, that would be much
more efficient if performed on Manticore side.
$cutoff
setting is intended for advanced performance control. It
tells searchd
to forcibly stop search query once $cutoff
matches
had been found and processed.
SetMaxQueryTime¶
Prototype: function SetMaxQueryTime ( $max_query_time )
Sets maximum search query time, in milliseconds. Parameter must be a non-negative integer. Default value is 0 which means “do not limit”.
Similar to $cutoff
setting from
SetLimits(), but limits
elapsed query time instead of processed matches count. Local search
queries will be stopped once that much time has elapsed. Note that if
you’re performing a search which queries several local indexes, this
limit applies to each index separately.
SetOverride¶
DEPRECATED
Prototype: function SetOverride ( $attrname, $attrtype, $values )
Sets temporary (per-query) per-document attribute value overrides. Only supports scalar attributes. $values must be a hash that maps document IDs to overridden attribute values.
Override feature lets you “temporary” update attribute values for some documents within a single query, leaving all other queries unaffected. This might be useful for personalized data. For example, assume you’re implementing a personalized search function that wants to boost the posts that the user’s friends recommend. Such data is not just dynamic, but also personal; so you can’t simply put it in the index because you don’t want everyone’s searches affected. Overrides, on the other hand, are local to a single query and invisible to everyone else. So you can, say, setup a “friends_weight” value for every document, defaulting to 0, then temporary override it with 1 for documents 123, 456 and 789 (recommended by exactly the friends of current user), and use that value when ranking.