-
Notifications
You must be signed in to change notification settings - Fork 510
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add is_source
query parameter to transaction endpoints
#4035
Add is_source
query parameter to transaction endpoints
#4035
Conversation
DROP INDEX by_account; | ||
DROP INDEX by_fee_account; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stellar/horizon-committers Please double check these indices aren't used (I couldn't find a reason to keep them)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
by_account
I thought this would be used by GET /account/:account_id/transactions
, but it looks like it joins/filters on the history_transaction_participants
table, instead. Seems ok to remove, but is there a safer way to check that?
by_fee_account
I could've sworn I recalled either a PR or an issue that lets people filter fee-bump transactions by their fee source... can't find it now, maybe someone else remembers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't find any cases where the indexes are used. We can monitor the latencies in staging with mirroring on to verify there is no performance degradation
955e1cb
to
ffb7dab
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems good to me, minor notes below ⬇️
DROP INDEX by_account; | ||
DROP INDEX by_fee_account; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
by_account
I thought this would be used by GET /account/:account_id/transactions
, but it looks like it joins/filters on the history_transaction_participants
table, instead. Seems ok to remove, but is there a safer way to check that?
by_fee_account
I could've sworn I recalled either a PR or an issue that lets people filter fee-bump transactions by their fee source... can't find it now, maybe someone else remembers.
GET /accounts/{source_account_id}/transactions_by_source
endpointis_source
query parameter to transaction endpoints
a013fd1
to
fe1bda6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
services/horizon/CHANGELOG.md
Outdated
### Changes | ||
|
||
* Add `is_source=true` parameter to transaction endpoints (e.g. `GET /accounts/{account_id}/transactions?is_source=true` ) to | ||
allow filtering transactions based on their source account. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
New line here a mistake?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The line was too long and it shouldn't make a difference in rendering.
DROP INDEX by_fee_account; | ||
|
||
-- recreate by_account index without the sequence, which will be used to query transactions by_source_account | ||
CREATE INDEX history_transactions_by_source_account ON history_transactions USING btree (account); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already have multicolumn index which contains account
:
"by_account" btree (account, account_sequence)
So I wonder if we need a new one. Postgres docs are not super clear on this but it seems queries should be fast if there are equality constraints on leading columns (so account
in our case).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why have an index on multiple columns if you only need it for one? (it would take less space)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, we're removing it! I get it, sorry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If creating the index will take 15 minutes, should we consider creating the index concurrently so that postgres doesn't lock the table during the 15 minutes? There are some caveats: https://www.postgresql.org/docs/9.1/sql-createindex.html#SQL-CREATEINDEX-CONCURRENTLY
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I used 15 minutes as an estimation, I didn't get to meassure it (we will find out when deploying to staging as part of testing)
services/horizon/CHANGELOG.md
Outdated
### Changes | ||
|
||
* Add `is_source=true` parameter to transaction endpoints (e.g. `GET /accounts/{account_id}/transactions?is_source=true` ) to | ||
allow filtering transactions based on their source account. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this filter by transaction source account only, or operation source account too, and what about fee account? Is the goal to find transactions that only consume sequence numbers of the account (transaction source account), or transactions where the account chose to do something (transaction source account, operation source account, fee account). cc @tyvdh
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved this discussion to #3688 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It filters by transaction source account only.
fe1bda6
to
f7066e1
Compare
f7066e1
to
697945b
Compare
…llar#4035)" This reverts commit cecc89b.
I'm happy to use a different name for the endpoint.I usedtransactions_by_source
to distinguish it from the existing endpointGET /accounts/{account_id}/transactions
Closes #3688