-
Notifications
You must be signed in to change notification settings - Fork 563
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shortcut CASE evaluation (lazy scalar subquery evaluation) #16022
Comments
This is actually kinda the case, except that we also have a constant-folding/normalization step to reduce operations like In your example the How does the expensive lookup in your actual use-case look like? |
It is along the lines of something like this: CREATE TABLE invoices (
some_data TEXT
,customer_id INT
,invoice_specific_payment_terms TEXT
);
INSERT INTO invoices
SELECT 'abc',1,'60 days from receipt of invoice';
REFRESH TABLE invoices;
--> NB in this example invoice_specific_payment_terms is never NULL
CREATE TABLE customers (
customer_id INT
,customer_default_payment_terms TEXT
);
INSERT INTO customers
SELECT 1,'30 days from receipt of invoice';
REFRESH TABLE customers;
CREATE TABLE distributed_summits AS
SELECT * FROM sys.summits;
ANALYZE;
SELECT some_data,
CASE
WHEN invoice_specific_payment_terms IS NOT NULL
THEN invoice_specific_payment_terms
ELSE ( SELECT customer_default_payment_terms
FROM customers
CROSS JOIN distributed_summits s1
CROSS JOIN distributed_summits s2
CROSS JOIN distributed_summits s3
WHERE customers.customer_id=invoices.customer_id
ORDER BY s3.height DESC
LIMIT 1
)
END
FROM invoices; |
That's a bigger topic then as subqueries are generally treated in a special way, independent of the evaluation logic of an expression. |
Problem Statement
I have a query where on a limited number of cases an expensive lookup needs to take place.
At the moment
CASE
,COALESCE
, andIF
all result on the lookup taking place for all rows.Example:
Possible Solutions
Only evaluate "the arguments that are needed to determine the result" as in https://www.postgresql.org/docs/current/functions-conditional.html
Considered Alternatives
Store intermediate results on working tables and then use a query with an
UNION
considering the different cases.The text was updated successfully, but these errors were encountered: