Add Solana gas fees model

[0xBoxer]

This PR adds the Solana gas fees model, excluding source and documentation parts.

[Deluaney1]

Excellent

[0xBoxer]

logic checks pass and I think I caught all edgecases now.
for some reason the incremental build is slower than the non-incremental build even though it should be 1d versus 9 days, can't really see why, need help debugging.

[0xBoxer]

the incremental build spits out errors because it doesn't have prices for the most recent transactions, could hard limit to some 30 minute delay or smth cut-off date

[0xBoxer]

will open up non-incremental to a month now to see how that changes runtimes

[0xRobin]

• runtime optimization - I think I did all I can here to optimize the joins and operations tbh, but would appreciate a second set of eyes

looks good to me.

• prices.usd lags behind by a few minutes, so the prices left join for the most recent transactions fails, do we solve that by using prices.usd_latest usually?

we can use prices.usd_forward_fill which is a view that does a forward fill for the last hour to catch any price lags

[0xRobin]

this looks good to me, I don't see any further reasons why incremental is taking longer.

[0xBoxer]

also don't have anything more to change here, should be good to merge

[0xBoxer]

before merging we need to take out all {{if not is incremental}} filters

[jeff-dude]

this looks good to me, I don't see any further reasons why incremental is taking longer.

agreed on setup looking good. can't help but wonder how much incremental time increases when history is expanded extensively (larger table to lookup on in merge). this is only on 10 days of history? oof.

will require us to watch first run after merge + next few incremental to see how it's looking for sure

[0xBoxer]

This incremental predicate should keep it from getting slower though. The amount of hashes to merge into should stay roughly static if this limits the range of hashes to compare against.

incremental_predicates = [incremental_predicate('DBT_INTERNAL_DEST.block_time')],

[jeff-dude]

This incremental predicate should keep it from getting slower though. The amount of hashes to merge into should stay roughly static if this limits the range of hashes to compare against.

incremental_predicates = [incremental_predicate('DBT_INTERNAL_DEST.block_time')],

oh yes, of course, should be good

[jeff-dude]

i wonder if our issue on incremental could be around block_date and block_time being different columns in solana raw data, and the engine can't tie them together in terms of filter --> partition?

on evm raw tables, they are views where block_date is built off block_time raw data. the engine can tie them together from that and infer when searching partitions.

here we set block_date as partition, but filter incrementally on block_time and maybe the engine isn't catching that relationship?

[0xBoxer]

reasonable hypothesis - can we change { incremental_predicate('block_time') }} to {{incremental_predicate('block_date') }} ?

no way to loose the connection that way

[jeff-dude]

doesn't hurt to give it a shot. we could also update the source incremental filters to match the updated target one

[0xRobin]

I'll run some tests to see

[0xRobin]

ok, this is as optimized as we can get it. I guess it's just the raw amount of rows that is causing the incremental to take so long :(
I'll merge this tomorrow morning.