Replies: 3 comments
|
I looked at the number of queries for opening a card. When I open a card, I see from development log this: It is 41+12+4+14+9+11+9+16 = 116 queries total. Coming from a background of avoiding N+1 queries because the database could be in a different location and could have some ping time, this looks rather excessive. |
0 replies
|
i need a break for today ..... please drop a mail today by morning, if incase of problem |
0 replies
|
i have some medical issue please coordinate with sharma ,or else you can drop me a mail for it |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
In Fizzy, the design about "card properties" is that a separate entity is created whenever an action is taken on a card. Closing a card creates a closure entity, gilding a card creates a goldness entity, etc. This "entity approach" helps with putting additional data into entities, in Fizzy it is often a single field
user_id(closed by whom) but sometimes just the bare-bones entity without additional fields is created such as goldness.I'm afraid to do this design for two reasons:
When filtering through the
cardstable and using these properties, it requires aLEFT JOIN. With so many fields, there could be performance issues because after 4-6 JOINs the SQL planner refuses to guess the most optimal order and just uses the naive order of these joins.To load a single card with full data, it requires X queries, one for each property. Isn't it too much? Example from
Card:this requires 15 separate queries if I count it right.
The alternative approach is to add fields into the
cardstable such asclosed_at,closed_byetc. It avoids performance issues outlined above but clutters thecardstable.Could you explain the design decisions and performance caveats behind this approach? Thank you.
All reactions