Re:Implementing "seen by" functionality with Postgres
by yjftsjthsd-h on Tuesday July 19, 2022 @12:47AM
(#32147649)
That sounds like it's a bad benchmark, then? I mean, it's still interesting, but a synthetic benchmark that fails to map to real use is... I guess actually negative value since it's misleading.
Re:Implementing "seen by" functionality with Postgres
by nnnnnande on Monday July 18, 2022 @01:44PM
(#32141032)
Yeah, this is probably the reason and the author even elaborates on this in the sentences following the bit quoted by cldellow:
> Even though the data says hstore, knowing that posts will be seen by more and more people over time, I might choose the HLL solution for an actual implementation. It's far less likely to pose a bloated row problem, [...]
Re:Implementing "seen by" functionality with Postgres
by hardwaresofton on Monday July 18, 2022 @03:51PM
(#32142777)
Just posting here too, but yup this is exactly what I was trying to convey.
Hstore might have been the fastest but the way I am using it or the scales the use case could scale to might not work out.
Bigger benchmarks could have been done! Maybe a multi part post would have been better so I could split apart methodology and results/blabbering about approach!
Re:Implementing "seen by" functionality with Postgres
by hardwaresofton on Monday July 18, 2022 @03:48PM
(#32142729)
Yup this is it! You’ve said it much better than I did, thank you.
Just guessing: the benchmark tells you the time complexity. It doesn't tell you the space complexity. The author is optimizing between the time- and space-complexity of the solutions, with the time-complexity benchmarks as an input. (Also, at a scale the benchmark doesn't reach, space-complexity starts to affect time-complexity, as large datasets become less able to be hot in disk cache.)