TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Show HN: pg_plan_guarantee – Postgres Query Optimizer Hints, on Steroids.

46 pointsby gurjeetabout 3 years ago

2 comments

gurjeetabout 3 years ago
I have been in the following situation, and anecdotally I know many other DBAs and Developers have also bitten by such a situation. Hence I created this Postgres extension, to save us from the tyranny of a Query Optimizer :-). Following is directly from the project&#x27;s Overview section.<p>You work very hard to tune your queries; to get the exact query execution plan that satisfies your performance needs.<p>But some time later, after either the data has changed suffiently, or the statistics have changed sufficiently, Postgres planner chooses to suddenly pick a query execution plan that makes your application look unresponsive. This shows up on your dashboard as an outage. Now you find yourself running against the clock, to rewrite the query, test it, change the application&#x2F;ORM, and deploy the changes, and still just hoping that the production database accepts your offerings, and executes your query just acceptably enough, so you can go back to bed.<p>But if you use the pg_plan_guarantee extension, you will never face such a situation; we can guarantee that. This extension provides a mechanism, using which you can set your execution plan in stone; that is, Postgres will execute the plan you give it, or it will throw an error, but it will never try to guess a plan for you.<p>Because the data and&#x2F;or statistics change gradually over time, you can be fairly confident that the guaraneed-plan will continue to serve your needs in a graceful manner. That is, your guaranted-plan will degrade gracefully, as opposed to suddenly, at the most inopportune time.
评论 #30829345 未加载
评论 #30831742 未加载
gurjeetabout 3 years ago
Some interesting discussion starting on Reddit as well.<p>Notably, sir_bok says: ... it is better to be uniformly slow than to risk a performance cliff where everything seems fine until it suddenly isn&#x27;t. At least uniformly bad performance (or a gradual performance decline) is predictable and can be worked around by the users. You also have more time to react.<p><a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;PostgreSQL&#x2F;comments&#x2F;tpw6fq&#x2F;new_extension_pg_plan_guarantee_guarantee_that&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;PostgreSQL&#x2F;comments&#x2F;tpw6fq&#x2F;new_exte...</a>