Overcoming speed issue when having a complex query

I have a complex query:

It takes 23 secs to load the data even if I limit it to 10 rows.

So I see two options:

  1. Add some extra fields to the Slot thing to be able to create a faster search. I don’t know if this is really possible since the speed issue comes from filtering out based on stuff not known when the Slot thing is created.
  2. Create a back end database trigger that does the search every time a Slot is created, thus creating a simple list that is fast to load.

Appreciate any thoughts on this.

Best, Peter

Hi Peter @philledille

This is my solution.

4 Likes

Peter,

Is this pinging an availability table?

Yes it is.

Thanks John for confirming!

Why don’t you connect the data types together with the current user. Should work much faster.

You can also load the expert’s availability as a state in the background and use that to extract the slots.

I personally work with relational data and find my web apps to be a lot faster.

Thnx for your thought on this - a new approach to me when considering speed.

I had a go at your thought, but (if I understand correctly) does not work for our use case since we need to create a lot of relations when a new user signs up. And that would take time and needed to be done back end. This takes us as back to the main problem of needing to load the slot list fast as soon as the user signs up or logs in.

My initial solution was to have a RG (visibile but not in view) to load all data. But this took so long time that the user still had to wait for it if starting the booking process directly when coming in to the page.

Thnx, Peter

@JohnMark @nocodeventure Actually it turned out that the solution would be a combination of my initial points 1 and 2. But the complexity and consequences (read time and money) was not worth it, since the filters are nice, not need, to have, and we are moving the whole calendar handling to Nylas. So I simply removed the one less needed(!)

Thnx, Peter

1 Like