[HN Gopher] Row Embedded Cache: Experimenting with a new pattern...
___________________________________________________________________
Row Embedded Cache: Experimenting with a new pattern of caching
Author : recroad
Score : 12 points
Date : 2024-08-08 13:11 UTC (1 days ago)
(HTM) web link (zarar.dev)
(TXT) w3m dump (zarar.dev)
| arrowleaf wrote:
| You can similarly use materialized views for this type of
| denormalization. When an update to the source tables occur you
| can trigger a view refresh.
| bastawhiz wrote:
| This is just denormalization.
|
| If you need to invalidate this "cache", it's extremely expensive
| to find the records that need updating. It's probably better to
| use a summary table that's populated with triggers, or to just
| optimize your indexes and use a JOIN (the world won't end, I
| promise).
| SPBS wrote:
| > KISS to the rescue.
|
| Ha. KISS would be sticking to left joins and profiling their
| performance (with the appropriate indexes added) and finding
| alternative solutions only when it's proven to be a problem,
| instead of... declaring left joins to be slow and immediately
| jumping the gun
| ecjhdnc2025 wrote:
| _All_ the relations: this is a bit excessive.
|
| But before CTEs this sort of thing had regular use with recursive
| tree structures, in caching hierarchies. You'd make use of
| whatever SQL options you had to concatenate a group of IDs into a
| comma-separated string.
|
| e.g. all the parent nodes of a given node in the hierarchy, and
| even (selectively) for caching all the descendent node IDs of
| enclosures. Though there are better ways to do this for trees
| that could be truly arbitrarily deep.
___________________________________________________________________
(page generated 2024-08-09 23:01 UTC)