New feature request: Query Rewrite Cache

From: Bert Scalzo <bertscalzo2(at)gmail(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: New feature request: Query Rewrite Cache
Date: 2020-03-09 12:46:49
Message-ID: CAFernC5R3J6zRza5FB0=MQ9U7Pe2MkT4SexTf6OMoQwmWBnS-Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

MySQL has a really useful feature they call the query rewrite cache. The
optimizer checks incoming queries to see if a known better rewrite has been
placed within the query rewrite cache table. If one is found, the rewrite
replaces the incoming query before sending it to the execution engine. This
capability allows for one to fix poorly performing queries in 3rd party
application code that cannot be modified. For example, suppose a 3rd party
application contains the following inefficient query: SELECT COUNT(*) FROM
table WHERE SUBSTRING(column,1,3) = 'ABC'. One can place the following
rewrite in the query rewrite cache: SELECT COUNT(*) FROM table WHERE column
LIKE 'ABC%'. The original query cannot use an index while the rewrite can.
Since it's a 3rd party application there is really no other way to make
such an improvement. The existing rewrite rules in PostgreSQL are too
narrowly defined to permit such a substitution as the incoming query could
involve many tables, so what's needed is a general "if input SQL string
matches X then replace it with Y". This check could be placed at the
beginning of the parser.c code. Suggest that the matching code should first
check the string lengths and hash values before checking entire string
match for efficiency.

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2020-03-09 12:47:18 Re: bad logging around broken restore_command
Previous Message Arseny Sher 2020-03-09 12:46:39 Re: logical copy_replication_slot issues