haha, part way through making a new algorithm out of the pieces

currently writing an event query function that does not fetch events unless it has to

there is two conditions it does this:

- where there is an author AND tags

- where there is tags AND kinds

for these cases, it has to grab the full events to run a query on those extra fields in the events because they don't have a second index (and i think it would be expensive to make

however, you can probably see that author/tag and tag/kind searches are probably fairly common

author/kind, doesn't need this

probably the majority of queries are this exact pattern, so it makes sense that the index is optimized towards them

anyway, it's too late at night for me to finish this algorithm, but i feel like it's going to be just a couple more pieces and done

mainly, i have created a new index that tracks the event ID, author pubkey, and the serial index key of the event in one. the majority of cases the index is already found and we know it matches, and for the other two cases, we accumulate these serials that match and then we need to search the full index, as i am calling it, and voila, we sort these found keys by the ascending/descending sort of timestamp and then extract the event Ids and return them

see, that's why i had to write this down, because i needed to explain it to myself

i need to be gathering the event serials of the matches, both the ones that match from author/kind and the ones that match from kind/tag and author/tag

and done