Query all nodes that contain links to nodes A __and__ B

[wuqui]

I'm very interested in being able to query my org-roam DB like with org-ql or logseq. I came across your package vulpea, but I didn't find any documentation on how to query the database, ideally beginner-friendly?

For example, I would like to do queries that return a list of all nodes that link to nodes A and B. Is something like this possible?

[d12frosted]

Hey @wuqui

Right now links are not part of vulpea-note hence vulpea-db-query will not help here. Reason for that is simple - I never needed, this but if someone needs, that I am totally fine adding them (considering performance penalty is neglectable).

So back to your specific question. This library already provides a function to find notes linked to current note - vulpea-find-backlink. If we look into its implementation, we can see that it uses org-roam-backlinks-get:

vulpea/vulpea.el

Lines 95 to 100 in d6792e9

	(let* ((node (org-roam-node-at-point 'assert))
	(backlinks (seq-map
	(lambda (x)
	(vulpea-db--from-node
	(org-roam-backlink-source-node x)))
	(org-roam-backlinks-get node))))

So we can just combine it into solution thanks to existence of seq-intersection. Let's say we want to find all notes that link note for Corinto grape (id feffc6de-9a35-449b-8470-e64b4f28832c) and Nero d'Avola (id c9731b65-61f8-4007-9dbf-d54056f55cc4). For simplicity it's going to show titles of notes that link them both.

(let* ((node1 (org-roam-populate
               (org-roam-node-create :id "feffc6de-9a35-449b-8470-e64b4f28832c")))
       (backlinks1 (seq-map #'org-roam-backlink-source-node
                            (org-roam-backlinks-get node1)))
       (node2 (org-roam-populate
               (org-roam-node-create :id "c9731b65-61f8-4007-9dbf-d54056f55cc4")))
       (backlinks2 (seq-map #'org-roam-backlink-source-node
                            (org-roam-backlinks-get node2))))
  (seq-intersection
   (seq-map #'org-roam-node-title backlinks1)
   (seq-map #'org-roam-node-title backlinks2)))

This returns the following list for me (first note is a description of wine that contains both grapes and the latter where I mention everything in one single journal note):

("Tenuta di Castellaro Nero Ossidiana 2015" "Saturday, 23 October 2021")

As opposed to this list, when I combine these two lists via seq-uniq:

("Tenuta di Castellaro Nero Ossidiana 2015" "Tenuta di Castellaro Corinto 2017" "Saturday, 23 October 2021" "Cerasuolo di Vittoria DOCG" "Frappato" "Donnafugata Tancredi 2016" "Tasca Regaleali Nero d'Avola 2017" "Firriato Santagostino Baglio Soria Nero d'Avola Syrah 2014" "COS Pithos Rosso 2010" "Gulfi NeroSanlorè 2013" "Gulfi neroBaronj 2016" "Gulfi Nerojbleo 2009" ...)

As you can see, none of vulpea functions are used here. Because org-roam is powerful enough by itself. If backlinks are first class citizen in vulpea (and again, if someone has the need for this I would take a look how to add them), the code would look like this:

(vulpea-db-query
 (lambda (note)
   (and (seq-contains-p (vulpea-note-backlinks note)
                        "feffc6de-9a35-449b-8470-e64b4f28832c")
        (seq-contains-p (vulpea-note-backlinks note)
                        "c9731b65-61f8-4007-9dbf-d54056f55cc4"))))

Hope that helps.

[wuqui]

Brilliant, thanks for this quick and excellent answer!

How could I turn this into an (interactive) function I can use? So from a user perspective, for this to be practically useful, you would probably want to be able to call a function and then interactively select >= 1 node and get a list of notes back?

I think this should be incredibly useful for lots of people in different use cases. I guess the fact that queries like this are very popular in Roam Research and logseq would be some empirical evidence that it's worth building something like this for org-roam.

[d12frosted]

Brilliant, thanks for this quick and excellent answer!

Glad you find it useful.

get a list of notes back

What do you mean by 'back'? :) Like, in interactive use there is no point in returning anything from a function as it's interactive use. But let me show you several examples.

First, here is a function that returns a list of backlinks for a given list of notes.

(defun vulpea-backlinks-many (notes)
  "Return notes that link to all NOTES at the same time."
  (let* ((blinks-all
          (emacsql-with-transaction (org-roam-db)
            (seq-map
             (lambda (note)
               (seq-map
                #'vulpea-db--from-node
                (seq-map
                 #'org-roam-backlink-source-node
                 (org-roam-backlinks-get
                  (org-roam-populate
                   (org-roam-node-from-id (vulpea-note-id note)))))))
             notes))))
    (seq-reduce
     (lambda (r e)
       (seq-intersection
        r e
        (lambda (a b)
          (string-equal (vulpea-note-id a)
                        (vulpea-note-id b)))))
     blinks-all
     (seq-uniq (apply #'append blinks-all)))))

Non-interactive usage example:

ELISP> (seq-map
        #'vulpea-note-title
        (vulpea-backlinks-many
         (list
          (vulpea-db-get-by-id "feffc6de-9a35-449b-8470-e64b4f28832c")
          (vulpea-db-get-by-id "c9731b65-61f8-4007-9dbf-d54056f55cc4"))))
("Tenuta di Castellaro Nero Ossidiana 2015" "Saturday, 23 October 2021")

Now we ca use it in many ways. For example, this will allow to interactively select several notes, and then select a title among these titles:

(defun select-backlinks-many ()
  "It's hard to explain."
  (interactive)
  (let* ((notes (vulpea-utils-collect-while
                 #'vulpea-select
                 nil
                 "Note" :require-match t))
         (blinks (vulpea-backlinks-many notes)))
    (completing-read
     "Blacklink: "
     (seq-map #'vulpea-note-title blinks))))

It uses a helper function from vulpea:

vulpea/vulpea-utils.el

Lines 89 to 111 in d6792e9

	(defun vulpea-utils-collect-while (fn filter &rest args)
	"Repeat FN and collect it's results until `C-g` is used.
	Repeat cycle stops when `C-g` is used or FILTER returns nil.
	If FILTER is nil, it does not affect repeat cycle.
	If FILTER returns nil, the computed value is not added to result.
	ARGS are passed to FN."
	(let (result
	value
	(continue t)
	(inhibit-quit t))
	(with-local-quit
	(while continue
	(setq value (apply fn args))
	(if (and filter
	(null (funcall filter value)))
	(setq continue nil)
	(setq result (cons value result)))))
	(setq quit-flag nil)
	(seq-reverse result)))

Basically, you initially select as many notes as you wish and stop this by pressing C-g, and then it will prompt for backlinks.

Update

You can also select and visit backlink using this function:

(defun find-backlinks-many ()
  "It's hard to explain."
  (interactive)
  (let* ((notes (vulpea-utils-collect-while
                 #'vulpea-select
                 nil
                 "Note" :require-match t))
         (blinks (vulpea-backlinks-many notes))
         (note (vulpea-select-from
                "Backlink" blinks :require-match t)))
    (org-roam-node-visit
     (org-roam-node-from-id (vulpea-note-id note)))))

Selection happens the same. Hope that helps!

[Cletip]

Ah, require did the trick. Should have tried that. I thought it wasn't necessary if I had a use-package! block. Thanks!

I don't exactly why too :(

One additional question about it: is it possible to jump to nodes from the selection buffer that displays the candidates while leaving the selection buffer open? As in occur or swiper searches? As I said, I'm using Doom Emacs,f so I guess the relevant info is that this minibuffer comes from vertico (I think).

If I understand correctly, you want to do something like this:

vulpea-find -- find a note and open -- always have the search buffer after opening the note.

At first glance, it doesn't seem possible, but I recommend this package:

https://github.com/oantolin/embark

its principle is very simple: the command "embark-act" can be put anywhere, and allows to do actions: see the definition, apropos etc. It understands with the context. On a misunderstanding, it could solve this problem.
On the other hand, do an "embark-act" anywhere, just to test. I found some useful things

@d12frosted has maybe a better solution than me for that, and especially simpler ^^.

Lastly, I've discovered another issue: for some reason,vulpea only finds nodes in my agenda subdirectory, rather than my entire org-roam directory. But that's not related to your function, so I should probably ask somewhere else.

You should look at your total configuration. But maybe, look at the "org-roam-directory" and "org-directory" variables, I think that's where it comes from. Check in particular that all your files are present

[d12frosted]

Ah, require did the trick. Should have tried that. I thought it wasn't necessary if I had a use-package! block. Thanks!

This is because use-package! uses autoloads to defer loading of the package. Whenever you "evaluate" an autoloaded object (function, variable), the whole package is loaded. The common approach is to mark interactive functions (e.g. user facing) as autoloaded and leave 'library' functions not autoloaded. If you write your own code based on library functions, you are responsible for properly loading dependencies.

With use-package macro you can extend list of autoloads by using :commands argument. Not using Doom Emacs, but I guess their macro also supports it.

(use-package vulpea
  :commands (vulpea-utils-collect-while)
  ;; ... your settings
)

[d12frosted]

But how did you get started in the first place? Why did you know this "architecture"? Why don't you just make the functions larger?

It's off-topic. In short, functions without clear scope are harder to compose and to test. If I struggle to name a function, then probably it's implementation doesn't make sense.

has maybe a better solution than me for that, and especially simpler ^^.

I don't 😅 AFAIK, many completion interfaces provide a functionality to resume previous completion (e.g. you can select an item, completion ends, but you can resurrect it). Better UX requires investigation 😸

What I've been thinking to do is to provide a simple way to display a list of notes in a separate buffer as a list/table with links to the notes. Time to time I need to narrow down to a list of notes and process each of them in an interactive way.

[wuqui]

Good to know, plus it works – thanks 🙂

[Cletip]

thanks you for the conversation @d12frosted ^^

[d12frosted]

I've been playing around with links being part of note and so far I am not very pleased with performance. I mean, it's already possible to achieve desired outcome with nice(tm) API, but performance is not so pleasing. I am including benchmark numbers, so you shall make your own judgement.

TL;DR this is a long comment, so please jump to conclusion if you wish to skip all the details (which is totally understandable).

Benchmarks

I am going to benchmark every implementation using the following code:

(benchmark-run 100
  (seq-map
   #'vulpea-note-title
   (vulpea-backlinks-many
    (list
     (vulpea-db-get-by-id "feffc6de-9a35-449b-8470-e64b4f28832c")
     (vulpea-db-get-by-id "c9731b65-61f8-4007-9dbf-d54056f55cc4")))))

Maybe it's not the best way to benchmark, but it gives quite a good view on what's happening. Keep in mind that benchmark-run returns triplet of total run time, count of garbage collections and time spent on garbage collection.

I am running on 8390 notes. Which is not super big collection, but still not the smallest one.

And yes, I expect every implementation to behave like this:

ELISP> (seq-map
        #'vulpea-note-title
        (vulpea-backlinks-many
         (list
          (vulpea-db-get-by-id "feffc6de-9a35-449b-8470-e64b4f28832c")
          (vulpea-db-get-by-id "c9731b65-61f8-4007-9dbf-d54056f55cc4"))))
("Tenuta di Castellaro Nero Ossidiana 2015" "Saturday, 23 October 2021")

Using org-roam API

This is basically, the original implementation that I shared in this thread.

(defun vulpea-backlinks-many (notes)
  "Return notes that link to all NOTES at the same time."
  (let* ((blinks-all
          (emacsql-with-transaction (org-roam-db)
            (seq-map
             (lambda (note)
               (seq-map
                #'vulpea-db--from-node
                (seq-map
                 #'org-roam-backlink-source-node
                 (org-roam-backlinks-get
                  (org-roam-populate
                   (org-roam-node-from-id (vulpea-note-id note)))))))
             notes))))
    (seq-reduce
     (lambda (r e)
       (seq-intersection
        r e
        (lambda (a b)
          (string-equal (vulpea-note-id a)
                        (vulpea-note-id b)))))
     blinks-all
     (seq-uniq (apply #'append blinks-all)))))

Now, this produces the following results:

(28.974334 14 0.9528559999999999)

Which is quite fast, because 0.28s for one invocation is quite good as it occupies roughly 17 frames (if we talk about 60fps).

Using vulpea-db-query API

Previous implementation is quite cumbersome, so I my aim was to use my favourite vulpea-db-query (which I actually use so often!). But expectedly, it is not as fast as previous implementation, because it actually loads ALL notes into memory and then applies filtering as opposed to extraction of specific notes only. The only thing that came out unexpectedly is the order of magnitude of slowness.

(defun vulpea-backlinks-many (notes)
  "Return notes that link to all NOTES at the same time."
  (vulpea-db-query
   (lambda (note)
     (seq-every-p
      (lambda (n)
        (seq-contains-p
         (vulpea-note-links note)
         (cons "id" (vulpea-note-id n))))
      notes))))

So this looks nice indeed. I mean, with such implementation one could argue that vulpea doesn't need any helper like this, cause it's so easy... But since collection of notes is becoming bigger and bigger, this fancy function only degrades in terms of performance.

(228.282158 100 8.325743)

So it takes 2.2 second to find result. Which is bad, but to be honest it is not THAT bad. Though bad enough for me to search for another solution.

Specialized SQL query

And what can be faster that writing very specific SQL queries? I don't know yet, but let's discover this implementation:

(defun vulpea-backlinks-many (notes)
  "Return notes that link to all NOTES at the same time."
  (emacsql-with-transaction (org-roam-db)
    (seq-map
     (lambda (v)
       (vulpea-db-get-by-id (car v)))
     (org-roam-db-query
      (string-join
       (seq-map
        (lambda (v)
          (format "select source from links
where links.\"type\" = '\"id\"'
and links.dest = '\"%s\"'"
                  (vulpea-note-id v)))
        notes)
     "\nintersect\n")))))

Basically, it builds a SQL query that looks like this in our example:

select source from links
where links."type" = '"id"'
and links.dest = '"feffc6de-9a35-449b-8470-e64b4f28832c"'
intersect
select source from links
where links."type" = '"id"'
and links.dest = '"c9731b65-61f8-4007-9dbf-d54056f55cc4"'

And then executes it to get unique list of ids that link to these two notes. After that it simply queries full notes for result. Since in our case we are talking about two notes as a result, it works blazingly fast:

(2.2780650000000002 1 0.07669800000000038)

So it's 10 times faster than original solution using org-roam API and more than 100 times faster than vulpea-db-qeury - only 0.0227s to query all the information, which is 1.36 frames (ok, ok 2 frames) for 60fps.

Extra benchmarks

Since it's not fair to make any conclusions based on this particular use case, let's also cover two extremes.

The most linked note

So first extreme is when result of our function returns lots of notes. For this I have found the most linked note:

select dest, count(1) from links
group by dest
order by count(1) desc

In my case, the winner is note with id c6c8738e-3780-44b1-9e8c-d2fff16ed206, which is linked 358 times. So we benchmark it once again:

(benchmark-run 100
  (seq-map
   #'vulpea-note-title
   (vulpea-backlinks-many
    (list
     (vulpea-db-get-by-id "c6c8738e-3780-44b1-9e8c-d2fff16ed206")))))

The results are the following:

• org-roam API: (185.930086 93 7.528362999999999)
• vulpea-db-query: (234.636907 100 9.894120000000001)
• specialized query: (142.250805 56 4.834163000000004)

Much slower results are expected as more time is spent in querying 358 notes. What is also important and expected - the difference between results is not that critical now (e.g. 1.8s vs 2.3s vs 1.4s), because we still need to get lots of data. Though specialized query approach is a clear winner here.

Big intersection

Now the other extreme is when we want to find all notes that link to big list of notes at the same time. Let's say 358 notes is big enough. Of course, the resulting list of notes is empty, but let's see how the code behaves when it needs to search for big intersection criteria.

(let ((notes (seq-take (vulpea-db-query) 358)))
  (benchmark-run 100
    (seq-map
     #'vulpea-note-title
     (vulpea-backlinks-many-old
      notes))))

The results are the following:

• org-roam API: (453.420141 202 17.247912)
• vulpea-db-query: (227.249325 100 10.567296999999996)
• specialized query: (46.843158 1 0.2470909999999975)

The most interesting part here is that org-roam API based solution is very slow. Mostly because it needs to perform too many queries. Also it's interesting to see that intersection of 358 selects doesn't provide that huge overhead and is quite manageable.

Full results

Here is a table displaying full results. Each value is seconds of single run (e.g. benchmark result of running 100 times divided by 100).

test	org-roam	vulpea-db-query	specialized
simple	0.28974334	2.28282158	0.022780650000000002
popular	1.85930086	2.34636907	1.42250805
big intersection	4.53420141	2.27249325	0.46843158

Conclusion?

So now that we have all the data, we can draw some conclusions.

First and foremost, I am pleased that vulpea-db-query is the most stable in terms of performance across various test cases. While it is the slowest in real-world scenario, it is also the most powerful and generic solution - you can combine many predicates into one based on id, path, level, title, aliases, tags, links, properties and meta. So IMHO, this function is great 😸

Secondly, vulpea needs more specialized queries. As you can see, this simple solution outperforms all other. Since real world is full of cases where you need to query by one specific field only, it only makes sense to provide these specialized functions. I am thinking on including the following functions at the beginning:

• vulpea-db-query-by-tags-some - return all notes that are tagged at least by one tag from the given list of TAGS;
• vulpea-db-query-by-tags-every - return all notes that are tagged by each tag from the given list of TAGS;
• vulpea-db-query-by-links-some - return all notes that link to at least one note from the given list of NOTES;
• vulpea-db-query-by-links-every - return all notes that link to each note from the given list of NOTES;

I will definitely come up with more functions, but this should cover so many use cases that I have or plan to have in vino.

[d12frosted]

Sure, just let me know when it's ready. Glad if I could/can help 🙂

🙇 Thank you. It will take a while, hopefully will be ready somewhere next week.

Do you think vulpea might turn into something like org-ql for fast, database-based queries of org-roam collections some day?

Well, you kind of can use it already for programmatic search. But it seems like org-ql is a full blown query language. Maybe in the future `vulpea' will support this QL, but no plans for that at this point of time.

[d12frosted]

Well, you kind of can use it already for programmatic search. But it seems like org-ql is a full blown query language. Maybe in the future `vulpea' will support this QL, but no plans for that at this point of time.

Just realised that it's note true. vulpea has no functionality to search inside arbitrary 'content'. Via org-roam it provides ability to quickly search by things like id, title, path, tags, aliases, properties, meta, level and links. Anything else needs to be done manually.

But maybe it's an interesting direction to dig into - to provide more search capabilities. It's just kind of out of the scope right now.

[wuqui]

Well, you kind of can use it already for programmatic search.

Yeah, that's cool already. As I said above, I think I haven't yet managed to see the full potential, probably in large parts just because I'm failing to see what the functions could do for me without concrete examples.

But maybe it's an interesting direction to dig into - to provide more search capabilities. It's just kind of out of the scope right now.

Yeah, I think there's huge potential there. org-ql is great as a query language and I think lots of people use it. But it's limited since it operates on files rather than a (SQL) DB. Being able to use an interface like org-ql on top of the (org-roam) database would be amazing. As far as I remember, I read some time ago that the author of org-ql at least considered moving in that direction, but I'm not sure.

I also read quite a while ago that John Kitchen uses SQL to query his org files (blog post). Sounds great, but doesn't offer the user comfort and interactivity as something like org-ql. I don't know these things can be married and whether someone wants to put in the effort, but to me it seems very appealing 🙂

[tefkah]

Very out of the blue possibly extremely uninformed comment, but wouldn't it be much faster to do a single SQL query with IN and automatically collecting the nodes, rather than doing multiple queries for each set of backlinks, intersecting them and then doing another sql query to find the node? Something like

(org-roam-db-query  `[:select * :from nodes :where (in id `[:select source :from links
:where (= links:type "id")
:and (in links:dest ["feffc6de-9a35-449b-8470-e64b4f28832c"
     "c9731b65-61f8-4007-9dbf-d54056f55cc4"])])])

(i used different notes of course, at most 6 links per node or something)

For 2 notes, this was
(0.033625 0 0.0)

For 3 notes, this was
(0.068502 0 0.0)

I can't really directly compare it with your method, as I don't use vulpea, but vs this

(benchmark-run 100
  (emacsql-with-transaction (org-roam-db)
    (seq-map
     (lambda (v)
       (org-roam-node-from-id (car v)))
     (org-roam-db-query
      (string-join
       (seq-map
        (lambda (v)
          (format "select source from links
where links.\"type\" = '\"id\"'
and links.dest = '\"%s\"'"
                   v))
["feffc6de-9a35-449b-8470-e64b4f28832c"
     "c9731b65-61f8-4007-9dbf-d54056f55cc4"]
)
     "\nintersect\n")))))

For 2 notes, this was
(0.073505 0 0.0)

For 3 notes, this was
(0.27651400000000004 1 0.18441700000039418)

Note that in both cases we start with ids instead of notes, so mapping them to nodes isn't the issue.

Might be that there is some difference in implementation of Vulpea that the above won't work, but hope it's useful!

[d12frosted]

@ThomasFKJorna thanks for your comment 😸

(org-roam-db-query  `[:select * :from nodes :where (in id `[:select source :from links
:where (= links:type "id")
:and (in links:dest ["feffc6de-9a35-449b-8470-e64b4f28832c"
     "c9731b65-61f8-4007-9dbf-d54056f55cc4"])])])

It seems to me that we are solving different problems 🤔 As far as I understand this SQL, it finds all nodes linked to at least one of the passed ids (in this case feffc6de... and c9731b65...). However the goal is to find those nodes who link to all of the passed ids.

> (org-roam-db-query
 `[:select title :from nodes :where (in id `[:select source :from links
                                             :where (= links:type "id")
                                             :and (in links:dest ["feffc6de-9a35-449b-8470-e64b4f28832c"
                                                                  "c9731b65-61f8-4007-9dbf-d54056f55cc4"])])])
(("Alessandro Viola Rosé 2020")
 ("Gulfi Nerojbleo 2017")
 ("Donnafugata Tancredi 2016")
 ("Planeta Plumbago 2016")
 ("Feudo Maccari Neré 2018")
 ("Donnafugata La Bella Sedàra 2017")
 ...
 ("Alessandro Viola Rosso Isi 2019")
 ("Firriato Quater Vitis 2014")
 ("COS Cerasuolo di Vittoria Classico 2015"))

But instead I was expecting to get only two nodes that link to feffc6de... and c9731b65... and the same time.

Might be that there is some difference in implementation of Vulpea that the above won't work, but hope it's useful!

Nothing really vulpea related so far 🤔 And your snippet is really useful, because vulpea provides two functions right now to query by links:

• vulpea-db-query-by-links-some - that works exactly as your snippet, e.g. returns notes that link to at least one of the passed destinations
• vulpea-db-query-by-links-every - returns notes that link to all passed destinations.

And I like your idea of having one query to collect all data. So... I decided to play around with this idea. This is current implementation of vulpea-db-query-by-links-some. Basically, two queries are made - first to fetch the list of note ids and the second one is to fetch notes by a list of ids.

(defun vulpea-db-query-by-links-some (destinations)
  "Query a list of `vulpea-note' from database.

Only notes that link to at least one destination from the list of
DESTINATIONS are returned."
  (emacsql-with-transaction (org-roam-db)
    (vulpea-db-query-by-ids
     (seq-map
      #'car
      (org-roam-db-query
       (format "select distinct source from links where dest in %s"
               (emacsql-escape-vector
                (apply #'vector (seq-map #'cdr destinations)))))))))

(defun vulpea-db-query-by-ids (ids)
  "Query list of `vulpea-note' by IDS."
  (let* ((rows
          (org-roam-db-query
           (format
            "select
  id,
  path,
  \"level\",
  title,
  properties,
  aliases,
  tags,
  meta,
  links
from notes
where notes.id in %s"
            (emacsql-escape-vector (apply #'vector ids))))))
    (seq-mapcat
     #'vulpea-db--notes-from-row
     rows)))

Now, let me change implementation to use your trick (I am inlining SQL as it works faster).

(defun vulpea-db-query-by-links-some-single (destinations)
  "Query a list of `vulpea-note' from database.

Only notes that link to at least one destination from the list of
DESTINATIONS are returned."
  (seq-mapcat
   #'vulpea-db--notes-from-row
   (org-roam-db-query
    (format
     "SELECT * FROM notes WHERE id IN (SELECT source FROM links WHERE links.type = '\"id\"' AND links.dest IN %s);"
     (emacsql-escape-vector
      (apply #'vector (seq-map #'cdr destinations)))))))

And then I run the benchmarks :) And here are results:

[00:20.629]  [vulpea-db-query-by-links-some-single] begin benchmark with 10 invocations
[00:22.870]  [vulpea-db-query-by-links-some-single] benchmark result is (2.2408159999999997 34 1.3603679999999994) after 10 invocations => 1767 notes
[00:22.870]  [vulpea-db-query-by-links-some] begin benchmark with 10 invocations
[00:26.362]  [vulpea-db-query-by-links-some] benchmark result is (3.492386 49 2.1438930000000003) after 10 invocations => 1767 notes
[00:26.362]  [vulpea-db-query] begin benchmark with 10 invocations
[00:36.941]  [vulpea-db-query] benchmark result is (10.578342000000001 65 5.856387000000002) after 10 invocations => 1767 notes

Which means, it works 1.55 times faster. The same situation with vulpea-db-query-by-tags-some. So I want to bring it to vulpea 😸

Two last questions @ThomasFKJorna

1. Would you like to contribute this? 🙏
2. Do you have ideas how to improve performance of vulpea-db-query-by-links-every (e.g. the problem described in this topic).

In any case, many thanks 💯