This repository has been archived by the owner on Jan 30, 2024. It is now read-only.
Check if it's practical to simplify the query structure with links using links2
#1144
Labels
enhancement
New feature or request
The current query structure has multiple stages:
OFFSET
/LIMIT
handling is also done here if required.MATERIALIZED
CTE to prevent PG from using some really bad query plans. Unfortunately there's no other way to create an optimization barrier that I know of.ORDER BY
,OFFSET
, andLIMIT
are handled here too.This is the structure I arrived at after a lot of testing with large test DBs. "Obvious" methods like subqueries or lateral joins did significantly worse in the worst case, even if they might have been faster in some easier cases. Unfortunately, this structure also requires complex queries that can be hard to understand and debug. It is designed to "handle" postgres and keep it in the happy path.
Since moving to the
links2
table and seeing how it performs compared to the previous table I've wondered if this complexity is still necessary nowadays. This is going to be a tracking issue for benchmarks and redesigns if alternatives shown to be desirable.MATERIALIZE
MATERIALIZE
MATERIALIZE
MATERIALIZE
MATERIALIZE
MATERIALIZE
MATERIALIZE
For each scenario, test the following variants:
For all queries, contracts have their types and one common and indexed
data
field specified. Both the root and the links have the same amount of random contracts but different types. The queries must return the the full contract as JSONB to prevent postgres from muddling the results with too much optimization.While I don't think it's useful to test these right away, the method must be able to skip, limit and order both root cards and links.
For the tests I'll use postgres 13.4 with the default configuration and with the database stored in a ramdisk.
The text was updated successfully, but these errors were encountered: