Optimising the performance of filter expressions

When you retrieve data from LUSID you can typically filter the result set to qualify the data returned.

For example, the following call to the ListInstruments API applies a filter expression of name startswith 'App' to retrieve just those instruments with 'App…'-like names:

curl -X GET "https://<your-domain>.lusid.com/api/api/instruments?filter=name%20startswith%20%27App%27" 
  -H "Authorization: Bearer <your-API-access-token>"

Note: There is a maximum URL length of 2048 characters that may impact the complexity of any filter expression you submit via the LUSID API. This restriction does not apply if you filter LUSID data using Luminesce.

As you can see from the table below, the slowest filter expressions are those that join multiple expressions together using the or operator. Note that other factors less easy to tabulate may also affect performance, such as the size of your LUSID dataset and the number of filter expressions you choose to join using either and or or.

Speed

Entity attribute to filter on

Filter operator

Example

Faster

Fields and nested fields

eq

name eq 'BP'

 

Identifiers

identifiers['Isin'] eq 'GB0007980591'

SHKs (portfolios only)

subholdingkeys[Transaction/Demo/Strategy] eq 'Income'

Single-value properties

properties[Instrument/Ibor/Industry] eq 'Energy'

Custom data fields (custom entities only)

fields['Address'] eq '1 Main Street'

Multi-value properties

properties[Instrument/Ibor/Industry] all (~ eq 'Energy')

Relationships (supported entities only)

relationships any (Instrument.name eq 'BP')

As above, in the same order

gt
gte
lt
lte
startswith
in

name startswith 'BP'

As above, in the same order

exists
neq
not exists
not in

name neq 'BP'

As above, in the same order

and

name eq 'BP' and domCcy eq 'GBP'

Slower

As above, in the same order

or

name eq 'BP' or domCcy eq 'GBP'