You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There’s a significant difference in performance when running the same query locally vs. in the dev environment, even though the query uses the same execution strategy in both environments.
Query:
SELECT
*
FROM stacks_blockchain_api.txs
WHERE canonical = true AND microblock_canonical = true AND block_height <= 157521 AND burn_block_time <= 1730591999
AND (
CASE
WHEN EXISTS (
SELECT 1
FROM pg_extension
WHERE extname = 'pg_trgm'
)
THEN similarity(contract_call_function_name, 'swab') > 0.3
ELSE contract_call_function_name ILIKE '%swab%'
END
)
ORDER BY burn_block_time DESC, block_height DESC, microblock_sequence DESC, tx_index DESC
LIMIT 30
OFFSET 0;
We've had several issues similar to this: a postgres query is relatively fast on a local machine, but slow in dev/staging. We've also seen instances where the query seems faster in prod or local when those environments are not under any load. I.e. a query may be fast on a highly provisioned machine that is not under load, but once it's under load that query ends end becoming a significant bottleneck.
It's generally a good rule of thumb that if a query is not performant in the dev/stg environment, then it will not be performant when used at scale in the prod environment.
With this particular query, I don't think we can squeeze out about 1-2 orders of magnitude better performance unless we make a significant change to the approach. I think we'd need to do something like: create a new table that is responsible for tracking search terms, and create a search query against that table. That approach may work but keep in mind it's more involved than it might seem at face value. It involves:
Create a new table in a sql migration file
Optimize the indexes for very fast search queries
Update several areas in the data ingestion code so that we write to this new table
Write an optimize sql read query against that new table
There’s a significant difference in performance when running the same query locally vs. in the dev environment, even though the query uses the same execution strategy in both environments.
Query:
Analysis output:
The text was updated successfully, but these errors were encountered: