#realy #devstr #progressreport
i'm getting to the last steps in writing the fulltext query filter handling parts, and i've written the handle for p tags, that was easy, there's an index for that
but there isn't an index for e tags, this is what the "extrafilter" is about in fiatjaf's query function in the badger database
i'm looking this up and down and i'm like, uh, there's no index for e tags, which are commonly needed to search for replies!
i think i have to go to the indexes now and create a new index for e-tags to make this work, because i really don't see how i can filter on them with the fulltext search with a full filter
and if i'm gonna make a new e tag index, then i can speed up normal filter searches a lot too
hilarious, but kinda annoying, i was all homed in on the fulltext search function and now i have to go sideways and add a new index and that will mean needing to rescan the indexes when i'm done building that, before i can expect this fulltext search to work
i'm kinda glad i'm digging deep into this key value store database indexing design stuff... i'm sure this is going to be valuable. i have already learned enough to build a reasonable set of indexes for my fiat mine data analysis stuff, but this is getting a step further advanced, after i've built this i can say i have built a fully capable database engine for nostr that is optimized to search for events... with that e tag index added it will slash the search time by maybe as much as 50% for regular kind 1 or general threaded queries.
mleku
npub1fj…mleku
2025-05-15 18:42:34
Author Public Key
npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmlekuPublished at
2025-05-15 18:42:34Event JSON
{
"id": "f977a2ff22e0c988bf62cb83aa4bdad7b97e7603f2e9c18e23f046139bddc8f4",
"pubkey": "4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f",
"created_at": 1747334554,
"kind": 1,
"tags": [
[
"t",
"realy"
],
[
"t",
"devstr"
],
[
"t",
"progressreport"
],
[
"client",
"noStrudel",
"31990:266815e0c9210dfa324c6cba3573b14bee49da4209a9456f9484e5106cd408a5:1686066542546"
]
],
"content": "#realy #devstr #progressreport\n\ni'm getting to the last steps in writing the fulltext query filter handling parts, and i've written the handle for p tags, that was easy, there's an index for that\n\nbut there isn't an index for e tags, this is what the \"extrafilter\" is about in fiatjaf's query function in the badger database\n\ni'm looking this up and down and i'm like, uh, there's no index for e tags, which are commonly needed to search for replies!\n\ni think i have to go to the indexes now and create a new index for e-tags to make this work, because i really don't see how i can filter on them with the fulltext search with a full filter\n\nand if i'm gonna make a new e tag index, then i can speed up normal filter searches a lot too\n\nhilarious, but kinda annoying, i was all homed in on the fulltext search function and now i have to go sideways and add a new index and that will mean needing to rescan the indexes when i'm done building that, before i can expect this fulltext search to work\n\ni'm kinda glad i'm digging deep into this key value store database indexing design stuff... i'm sure this is going to be valuable. i have already learned enough to build a reasonable set of indexes for my fiat mine data analysis stuff, but this is getting a step further advanced, after i've built this i can say i have built a fully capable database engine for nostr that is optimized to search for events... with that e tag index added it will slash the search time by maybe as much as 50% for regular kind 1 or general threaded queries.",
"sig": "2e660e5f2181df9c4c94cea1966476d9ef1f70436326029325f6e586130423b0029605db1ee6abc735d8ee4b79012b2c5f38865f1b735cafeadc78bbf9cbba02"
}