Doug Hoyte on Nostr: Thanks! "yesstr" is currently only a basic flatbuffers wrapper around the sync ...
Thanks!
"yesstr" is currently only a basic flatbuffers wrapper around the sync protocol from the Quadrable library. Quadrable itself is used for a few niche things currently, but I believe it will be a perfect fit for nostr.
strfry always has a plan for any possible query, even if it's not optimal. Worst-case scenario is it falls back to a full scan of an index. However: 1) all indices are clustered by timestamp, so since/until can be used to reduce the query execution time, and 2) scanning an index is actually really fast (millions of rows per second, depending on what proportion is in the page cache and how fast the disk is). This is similar to what any SQL DB will do too, in the case it can't find an appropriate index.
There are also some basic limits for queries that can optionally be configured, such as maximum value for "limit" in a query, maximum query execution time, a limit on the time in the past for records that can be queried, etc. I'm planning on watching the performance with real-world queries and figuring out what the best configuration ends up being.
"yesstr" is currently only a basic flatbuffers wrapper around the sync protocol from the Quadrable library. Quadrable itself is used for a few niche things currently, but I believe it will be a perfect fit for nostr.
strfry always has a plan for any possible query, even if it's not optimal. Worst-case scenario is it falls back to a full scan of an index. However: 1) all indices are clustered by timestamp, so since/until can be used to reduce the query execution time, and 2) scanning an index is actually really fast (millions of rows per second, depending on what proportion is in the page cache and how fast the disk is). This is similar to what any SQL DB will do too, in the case it can't find an appropriate index.
There are also some basic limits for queries that can optionally be configured, such as maximum value for "limit" in a query, maximum query execution time, a limit on the time in the past for records that can be queried, etc. I'm planning on watching the performance with real-world queries and figuring out what the best configuration ends up being.