Caching parsing/analysis of Query Grammar

[steve-chavez]

Problem

There are several steps we do for each request to become a generated query. e.g. for a GET:

postgrest/src/PostgREST/App.hs

Lines 167 to 173 in 1f13e43

	handleRequest :: AuthResult -> AppConfig -> AppState.AppState -> Bool -> Bool -> PgVersion -> ApiRequest -> SchemaCache -> Handler IO Wai.Response
	handleRequest AuthResult{..} conf appState authenticated prepared pgVer apiReq@ApiRequest{..} sCache =
	case (iAction, iTarget) of
	(ActionRead headersOnly, TargetIdent identifier) -> do
	wrPlan <- liftEither $ Plan.wrappedReadPlan identifier conf sCache apiReq
	resultSet <- runQuery roleIsoLvl (Plan.wrTxMode wrPlan) $ Query.readQuery wrPlan conf apiReq
	return $ Response.readResponse headersOnly identifier apiReq resultSet

Before that:

postgrest/src/PostgREST/App.hs

Lines 148 to 153 in 1f13e43

	apiRequest <-
	liftEither . mapLeft Error.ApiRequestError $
	ApiRequest.userApiRequest conf req body
	Response.optionalRollback conf apiRequest $
	handleRequest authResult conf appState (Just authRole /= configDbAnonRole) configDbPreparedStatements pgVer apiRequest sCache

Solution

Akin to "prepared statements", implement "prepared requests". We can make a hash of our input parameters and store the generated query. Then just execute the query using the arguments.

Notes

• Avoiding the ApiRequest step to parse the query parameters(?id=eq.3&col=lt.4) is not possible. If we switched to a grammar like ?id.eq=3&col.lt=4(https://github.com/PostgREST/postgrest/issues/2066`) it might be possible to avoid our query grammar parsing and only do some lighter parsing.
• If we use the SEARCH method(Implement new SEARCH/QUERY HTTP method to pass arguments in request body for read request #2125 (comment)) and only have placeholder parameters on the query params then it should be possible to completely avoid parsing.
• use a library like https://github.com/cocreature/lrucaching/
• check how postgresql does prepared statements to see if we can use similar modules
• similar idea to JWT caching #2698

[wolfgangwalther]

Avoiding the ApiRequest step to parse the query parameters(?id=eq.3&col=lt.4) is not possible. If we switched to a grammar like ?id.eq=3&col.lt=4(#2066) it might be possible to avoid our query grammar parsing and only do some lighter parsing.

Hm, I'm not sure what your goal is. Do you want to:

• hash the values 3 and 4, too?
• hash only the "structure", so kind of like a "parametrized request", similar to the prepared statement?

If you wanted to hash the values, too, you could just use the whole query string for the hash, no parsing required.

If not... then you'd need to parse way too much of the actual structure of the request before you could actually calculate the hash - you'd almost be there in that case.

The SEARCH example you gave would be fine with using the full query string as input for the hash, too.

[steve-chavez]

hash only the "structure", so kind of like a "parametrized request", similar to the prepared statement?
If not... then you'd need to parse way too much of the actual structure of the request before you could actually calculate the hash - you'd almost be there in that case.

Yes, only the structure. But as you mention that's not worth it. SEARCH looks good.

My motivation is that with #2523 and #1582 we're going to be putting more work at the Plan level. That will certainly not be zero cost in terms of perf.

---

#2771 will prove how much time we take for parsing/planning.