# query Published articles for query. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Eloquent Performance and Database Design: Evidence Before Eager Loading DevFeed: [Eloquent Performance and Database Design: Evidence Before Eager Loading]() Original publisher: [Read original article]() Author: Freek Van der Herten (freek@spatie.be) Published: 2026-09-11T12:30:27Z Content type: tutorial Language: en Sources: [freek.dev - all blogposts]() Topics: [Eloquent ORM](), [Database](), [Laravel](), [PHP]() Tags: [database](), [eager-loading](), [eloquent](), [indexes](), [laravel](), [optimization](), [performance](), [php](), [query]() ### AI overview A practical deep dive into improving Eloquent performance and database design for a growing team dashboard. It covers detecting N+1 queries, choosing aggregates and indexes, inspecting query plans, pagination, chunking, and transaction boundaries. ### Source excerpt A deep dive into Eloquent performance, from detecting N+1 queries to choosing aggregates, indexes, query plans, pagination, chunking, and transaction boundaries for a growing team dashboard. Read more ## Cache stampede: how one expired key takes down the database DevFeed: [Cache stampede: how one expired key takes down the database]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-09-05T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [Cache](), [Caching](), [Database](), [consistent hashing](), [Redis]() Tags: [cache-stampede](), [caching](), [connection-pool](), [consistent-hashing](), [distributed-systems](), [jitter](), [query](), [redis](), [reliability](), [thundering-herd](), [traffic](), [ttl]() ### AI overview This article explains how a cache stampede occurs when a hot key expires and many requests simultaneously recompute the same value against the database. It recommends TTL jitter to prevent synchronized expirations and request coalescing so only one caller recomputes while others wait or serve stale data. It also discusses cache warming and consistent hashing for broader cache-failure scenarios. ### Source excerpt A cache TTL is a scheduled simultaneous failure: every request being served from one key misses at the same instant and goes to the origin together. If the recompute takes two seconds, every request arriving during those two seconds also misses, so the pileup grows faster than it drains. Jitter on the TTL stops keys expiring in lockstep, and request coalescing so only one caller recomputes while the rest wait or serve stale is what stops a single expensive key from saturating the database. ## When JSONB columns create schema, consistency, and performance problems DevFeed: [When JSONB columns create schema, consistency, and performance problems]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-09-01T00:00:00Z Content type: article Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [data](), [Structured-data](), [JSON]() Tags: [data-modelling](), [indexing](), [jsonb](), [migration](), [outage](), [postgres](), [postgresql](), [query](), [schema](), [schema-design](), [toast]() ### AI overview The article explains why using JSONB to avoid recurring migrations can create hidden schema and data-consistency problems. It discusses runtime failures from inconsistent keys and types, difficulty identifying dependencies across consumers, and the storage and update costs of large PostgreSQL JSONB documents. ### Source excerpt JSONB is a good fit for genuinely open-ended data and a poor one for schema you did not want to commit to yet. Without a schema there is no NOT NULL, no type, no foreign key and no way to know which keys are load bearing, so every read becomes a parse and a cast that can fail at runtime. Large documents are stored out of line and compressed, which means reading one key can require fetching and decompressing the whole document, and updating one key rewrites all of it. ## ADD COLUMN is not always free, and the lock queue is what takes you down DevFeed: [ADD COLUMN is not always free, and the lock queue is what takes you down]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-08-26T00:00:00Z Content type: article Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [PostgreSQL](), [incident](), [Query (disambiguation)](), [migration](), [MySQL]() Tags: [ddl](), [incident](), [locking](), [migration](), [migrations](), [mysql](), [postgresql](), [query](), [queues](), [schema-design](), [timeout]() ### AI overview Adding a nullable column can cause an outage even when the schema change itself is nearly instantaneous. In PostgreSQL, ALTER TABLE may wait for a long-running query, and subsequent queries can queue behind the waiting lock request. Setting a short lock_timeout and retrying can prevent the migration from taking down the table. ### Source excerpt Modern PostgreSQL adds a column with a default as a metadata change, so the table is never rewritten and the migration itself is instant. The outage comes from lock acquisition instead: ALTER TABLE needs an ACCESS EXCLUSIVE lock, and while it waits behind one long-running query, every subsequent query queues behind the waiting ALTER because the lock queue is ordered. Setting lock_timeout to a couple of seconds and retrying converts that from an outage into a no-op. ## Connection pool sizing is a queueing theory problem, not a tuning knob DevFeed: [Connection pool sizing is a queueing theory problem, not a tuning knob]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-08-22T00:00:00Z Content type: article Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [connection pool](), [queueing theory](), [Latency](), [Database](), [Concurrency]() Tags: [capacity-planning](), [concurrency](), [connection-pool](), [cpu](), [database](), [database-performance](), [hikaricp](), [inference](), [latency](), [network](), [postgresql](), [query](), [queueing-theory]() ### AI overview This article explains how to size a connection pool using Little's law: concurrency equals throughput multiplied by connection holding time. It argues that increasing the pool beyond the database's parallel execution capacity can move the queue, increase latency, and leave throughput flat. It also identifies excessive holding time from network round trips, N+1 queries, long transactions, and model inference calls as common causes of pool exhaustion. ### Source excerpt Pool size follows from Little's law: concurrency equals throughput multiplied by holding time, so 500 requests per second each holding a connection for 20ms needs ten connections rather than a round number someone picked. Past the point where the database can execute requests in parallel, adding connections moves the queue rather than removing it, and latency grows while throughput stays flat. The number that actually reaches the database is the pool size multiplied by the instance count, which is usually the number nobody has calculated. ## Covering Indexes and Index-Only Scans in PostgreSQL DevFeed: [Covering Indexes and Index-Only Scans in PostgreSQL]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-08-18T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [PostgreSQL](), [Query (disambiguation)](), [data]() Tags: [b-tree](), [cache](), [covering](), [covering-index](), [database-performance](), [explain](), [heap](), [indexes](), [indexing](), [innodb](), [pages](), [postgresql](), [query](), [storage](), [vacuum]() ### AI overview This tutorial explains why a normal index scan may still be slow: after finding matching entries, the database follows a pointer into the table for each row. Covering indexes store the selected columns in the index and can avoid those heap reads. In PostgreSQL, index-only scans also depend on the visibility map marking pages all-visible, while SELECT * prevents the technique from being fully effective. ### Source excerpt A normal index scan finds matching rows and then follows a pointer into the table for every one of them, which is a random read per row. A covering index stores the columns the query selects, so the engine answers entirely from the index and skips those reads. In PostgreSQL this only works when the visibility map marks the pages all-visible, so an unvacuumed table will report Heap Fetches in EXPLAIN and give back most of the gain. SELECT star defeats the technique completely. ## Why your index is not being used, and why the planner is usually right DevFeed: [Why your index is not being used, and why the planner is usually right]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-08-16T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [Query (disambiguation)](), [MySQL](), [bug]() Tags: [bug](), [cardinality](), [database-performance](), [explain](), [function](), [indexes](), [indexing](), [mysql](), [postgresql](), [predicate](), [query](), [query-planner]() ### AI overview This tutorial explains why database indexes may not be used even when they exist. It focuses on inaccurate cardinality estimates caused by stale statistics, predicates that prevent index matching, implicit casts, and cases where sequential scans are the cheaper choice. ### Source excerpt An unused index is almost never a planner bug. It is usually a predicate the planner cannot match to the index, such as a function or an implicit cast applied to the column, or a cardinality estimate that is wrong because statistics are stale. When the estimate is right and the planner still refuses, it is often correct: past a few percent of the table, random access through an index costs more than reading the table sequentially. The diagnostic that matters is the gap between estimated and actual rows in EXPLAIN ANALYZE. ## How ORM N+1 Queries Create Hidden Request Latency DevFeed: [How ORM N+1 Queries Create Hidden Request Latency]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-08-02T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [Object-relational mapping](), [Latency](), [Monitoring](), [lazy loading](), [Database](), [connection pool]() Tags: [connection-pool](), [database](), [database-performance](), [hibernate](), [latency](), [lazy-loading](), [monitoring](), [n-plus-one](), [observability](), [orm](), [query](), [request]() ### AI overview This article explains how ORM lazy loading can turn a loop over orders into an N+1 query pattern. Individual queries may remain fast and avoid slow-query alerts, while the accumulated network round trips increase request latency and hold connection-pool resources. It recommends monitoring queries per request and asserting query counts in tests. ### Source excerpt N+1 queries hide from monitoring because no individual query is slow. Four hundred queries at 0.4ms each never appear in the slow query log, never move p99 query latency, and still cost the request 300ms because the expense is the round trip rather than the execution. The metric that catches it is queries per request, and the only durable fix is asserting on that count in tests, since the code that causes it looks like a field access rather than I/O. ## Detecting Full Table Scans With SQLite DevFeed: [Detecting Full Table Scans With SQLite]() Original publisher: [Read original article]() Published: 2026-07-15T15:26:22Z Content type: tutorial Language: en Sources: [Aaron Patterson]() Topics: [SQLite](), [Databases](), [Development](), [Rails]() Tags: [database](), [index](), [query](), [rails](), [sqlite](), [test]() ### AI overview This tutorial shows how to detect full table scans in SQLite by inspecting prepared-statement statistics after executing a query. It demonstrates checking full-scan steps, then adding an index to eliminate the scan, and discusses possible Rails integration for test or development warnings. ### Source excerpt I'm at RubyConf this week, and it's great! I recently read that lobste.rs is now running on SQLite. One part from the post caught my attention: I wish we could say in a test, "Fail if you encounter any full table scans". Which would have caught the perf issues we experienced during the first deploy. SQLite collects information about prepared statements and exposes those statistics though an API. The upshot of this is that we can tell whether a statement did a full table scan after executing the statement without using an EXPLAIN. Here's an example program that demonstrates detecting a query did a full table scan: db = SQLite3::Database.new(":memory:") db.execute("CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT, age INTEGER)") # Insert a bunch of records 1_000.times do |i| db.execute("INSERT INTO users (name, age) VALUES (?, ?)", ["user#{i}", i % 100]) end def query(db) # Prepare a statement and query it stmt = db.prepare("SELECT * FROM users WHERE age = ?") stmt.bind_param(1, 42) stmt.to_a # Check the number of full scan steps to detect full table scan fullscan_steps = stmt.stat(:fullscan_steps) puts "fullscan_steps: #{fullscan_steps}" if fullscan_steps > 0 puts " => query performed a full table scan" else puts " => no full table scan" end end # No index, so we'll see a full table scan query(db) # Create an index db.execute("CREATE INDEX idx_users_age ON users(age)") # Added an index, so no full table scan query(db) Feels like we could integrate this in to Rails and warn or raise in test / development. I'm not sure if we'd want to check this all the time in production, but maybe it would be fine? ## How to Achieve Pruning When Querying by Non-Partitioned Columns in PostgreSQL DevFeed: [How to Achieve Pruning When Querying by Non-Partitioned Columns in PostgreSQL]() Original publisher: [Read original article]() Author: Haki Benita Published: 2026-07-08T21:00:00Z Content type: tutorial Language: en Sources: [Haki Benita]() Topics: [PostgreSQL](), [Databases]() Tags: [articles](), [how-to](), [index](), [partition](), [patterns](), [performance](), [postgresql](), [query]() ### AI overview This tutorial explains PostgreSQL partition pruning and shows how certain data patterns can enable pruning when queries filter on columns other than the partition key. It uses event data partitioned by year and examines queries by date range and session. ### Source excerpt Under conventional wisdom, pruning can only be achieved when querying by the partition key. However, if your data follows certain patterns, using some clever tricks you can achieve pruning even when filtering by non-partition key columns. ## The HTTP QUERY Method and RFC 10008 DevFeed: [The HTTP QUERY Method and RFC 10008]() Original publisher: [Read original article]() Author: ratneshmaurya2311@gmail.com (Ratnesh Maurya) Published: 2026-07-03T00:00:00Z Content type: tutorial Language: en Sources: [Ratn Labs]() Topics: [HTTP](), [Query (disambiguation)]() Tags: [api-design](), [backend](), [examples](), [http](), [query](), [web-development](), [web-development-http-backend-api-design]() ### AI overview This tutorial explains the HTTP QUERY method described in RFC 10008, including why GET and POST may be insufficient for complex searches and how QUERY works through examples. ### Source excerpt HTTP finally has a QUERY method. Learn what RFC 10008 changes, why GET and POST fell short for complex searches, and how QUERY works -- with simple examples. ## Dogfooding the Billable Actions metric: How granular observability improved our metering validation DevFeed: [Dogfooding the Billable Actions metric: How granular observability improved our metering validation]() Original publisher: [Read original article]() Author: Eric Chen Published: 2026-06-25T00:00:00Z Content type: article Language: en Sources: [Temporal Blog]() Topics: [observability](), [dashboards](), [Cloud](), [API](), [Server](), [Time Series](), [benchmarking]() Tags: [account](), [api](), [cloud](), [cost](), [count](), [dashboard](), [dashboards](), [dogfooding](), [metric](), [observability](), [optimization](), [query](), [raw](), [server](), [temporal-voices](), [time-series](), [validation](), [visibility]() ### AI overview Temporal describes how its Billable Actions metric and OpenMetrics per-type breakdowns provide more granular cost visibility. Internally, the company uses the metric with a canary account and validation dashboards to verify metering accuracy, troubleshoot discrepancies, and identify optimization opportunities. ### Source excerpt See how Temporal uses the Billable Actions metric internally to validate metering, troubleshoot discrepancies, and improve cost observability. ## Track customer loyalty points with durable workflows DevFeed: [Track customer loyalty points with durable workflows]() Original publisher: [Read original article]() Author: Cecil Phillip Published: 2026-06-03T00:00:00Z Content type: tutorial Language: en Sources: [Temporal Blog]() Topics: [account](), [business logic](), [Database](), [real-time](), [locking](), [retry](), [service](), [upgrade](), [Mobile]() Tags: [account](), [business-logic](), [customer](), [database](), [locking](), [loyalty](), [loyalty-points](), [mobile](), [process](), [query](), [real-time](), [retry](), [service](), [temporal](), [temporal-concepts](), [upgrades](), [workflows]() ### AI overview This article explains how to track customer loyalty points with durable Entity Workflows in Temporal. Each customer has a persistent workflow that maintains points, tier status, and activity history, while Signals handle accruals, Updates validate redemptions, and Queries read current balances. ### Source excerpt Track loyalty points with durable Entity Workflows in Temporal. See how to handle accruals, tier upgrades, and redemptions for each customer. ## LLM 训练与推理的基本理解 DevFeed: [LLM 训练与推理的基本理解]() Original publisher: [Read original article]() Author: Joway Published: 2026-05-17T00:00:00Z Content type: tutorial Language: zh Sources: [Random Thoughts]() Topics: [Large Language Model](), [Language models](), [Transformer]() Tags: [embedding](), [encoding](), [language](), [large-language-model](), [llm](), [model](), [query](), [tech](), [token](), [value]() ### AI overview This Chinese tutorial explains foundational LLM training and inference concepts, including vector operations, linear layers, Softmax, LayerNorm, tokenization, token IDs, BPE, token and positional embeddings, and the initial steps of self-attention using Q, K, and V vectors. ### Source excerpt 学习一个技术最好的方式就是能够写一片文章把这个技术的原理解释清楚，本文记录了我在阅读 《Build a Large Language Model (From Scratch)》一书以及和 Claude Code 对话过程中的笔记，仅供参考。 术语解释 向量点积 定义：向量点积为标量 a = (a1, a2, a3) b = (b1, b2, b3) a - b = a1*b1 + a2*b2 + a3*b3 几何意义： a - b = |a| |b| cos(theta) 其中 theta 是两个向量的夹角。 ## I Will Not Add Query Strings to Your URLs DevFeed: [I Will Not Add Query Strings to Your URLs]() Original publisher: [Read original article]() Published: 2026-05-09T00:00:00Z Content type: opinion Language: en Sources: [Susam Pal]() Topics: [Web Development](), [CSS](), [HTML](), [Self-hosted](), [C](), [C++](), [JavaScript](), [console](), [file]() Tags: [blog-post](), [c](), [c-plus-plus](), [css](), [developer](), [html](), [query]() ### AI overview The article reflects on Chris Morgan's opposition to query strings in URLs and connects that discussion to the author's experiences learning web development, CSS, HTML, and building the self-hosted Wander Console. ### Source excerpt Last evening, a short blog post appeared in my feed reader that felt as if it spoke directly to me. It is Chris Morgan's excellent post I've banned query strings. Contents Wisdom on the Web Wander on the Web Misfeature Broken URLs Qualms Conclusion Wisdom on the Web Chris is someone whose Internet comments I have been reading for about half a decade now. I first stumbled upon his comments on Hacker News, where he left very detailed feedback on a small collection of boilerplate CSS rules I had shared there. I am by no means a web developer. I have spent most of my professional life doing systems programming in C and C++. However, developing websites and writing small HTML tools has been a long-time hobby for me. I have learnt most of my web development skills as a hobbyist by studying what other people do: first by viewing the source of websites I liked in the early 2000s and later by occasionally getting possessed by the urge to implement a new game or tool and searching MDN Web Docs to learn whatever I needed to make it work. One problem with learning a skill this way is that you sometimes pick up habits and practices that are fashionable but not necessarily optimal or correct. So it was really valuable to me when Chris commented on my collection of boilerplate CSS rules. It helped me improve my CSS a lot. In fact, a few of the lessons from his comment have really stuck with me; I keep them in mind whenever I make a hobby HTML project: always retain underlines in links and retain purple for visited links. I have been following Chris's posts and comments on web-related topics since then. He often posts great feedback on web-related projects. Whenever I come across one, I make sure to read them carefully, even when the project isn't mine. I always end up learning something nice and useful from his comments. Here is one such recent example from the Lobsters story Adding author context to RSS. Wander on the Web A couple of months ago, I created a new project called Wan ## PostgreSQL temporal UPDATE and DELETE by range DevFeed: [PostgreSQL temporal UPDATE and DELETE by range]() Original publisher: [Read original article]() Author: depesz Published: 2026-04-02T10:51:21Z Content type: tutorial Language: en Sources: [select \* from depesz;]() Topics: [PostgreSQL](), [postgresql 18]() Tags: [delete](), [period](), [pg19](), [postgresql](), [query](), [range](), [temporal](), [uncategorized](), [update](), [version](), [waiting]() ### AI overview This article explains a PostgreSQL patch that extends UPDATE and DELETE for temporal tables, allowing changes or deletions over a specified range or multirange period. The article also notes that the patch was later reverted after discussion. ### Source excerpt Important update This has been reverted with some discussion. Thanks for ping to mkurz 🙂 On 1st of April 2026, Peter Eisentraut committed patch: Add UPDATE/DELETE FOR PORTION OF This is an extension of the UPDATE and DELETE commands to do a "temporal update/delete" based on a range or multirange column. The user can ... Continue reading "Waiting for PostgreSQL 19 - Add UPDATE/DELETE FOR PORTION OF" ## Waiting for PostgreSQL 19 - json format for COPY TO DevFeed: [Waiting for PostgreSQL 19 - json format for COPY TO]() Original publisher: [Read original article]() Author: depesz Published: 2026-03-29T12:34:22Z Content type: article Language: en Sources: [select \* from depesz;]() Topics: [PostgreSQL](), [JSON](), [export](), [data](), [Query (disambiguation)](), [interoperability]() Tags: [command](), [copy](), [data](), [developers](), [export](), [json](), [pg19](), [postgresql](), [query](), [stream](), [uncategorized](), [waiting]() ### AI overview The article discusses a PostgreSQL 19 patch adding a JSON format option to COPY TO. It allows table data or query results to be exported as a stream of JSON objects, one object per line, with an option to wrap the output in an array. ### Source excerpt On 20th of March 2026, Andrew Dunstan committed patch: json format for COPY TO This introduces the JSON format option for the COPY TO command, allowing users to export query results or table data directly as a stream of JSON objects (one per line, NDJSON style). The JSON format is currently supported only ... Continue reading "Waiting for PostgreSQL 19 - json format for COPY TO" ## Shazam finds songs by voting on time offsets, not by comparing audio DevFeed: [Shazam finds songs by voting on time offsets, not by comparing audio]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-03-16T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [Algorithm](), [hash](), [Databases]() Tags: [algorithm](), [algorithms](), [audio-fingerprinting](), [databases](), [hash](), [indexing](), [lookup](), [music-recognition](), [query](), [system-design]() ### AI overview The article explains how Shazam recognizes songs from short, noisy recordings. Instead of comparing audio similarity, it extracts spectrogram peaks, combines nearby peaks into hashes, and uses an inverted index to find tracks whose hash matches share a common time offset. The production system beyond the public 2003 paper is noted as unavailable. ### Source excerpt Shazam does not compare audio. It reduces each track to spectrogram peaks, pairs nearby peaks into ~32-bit hashes, and looks those up in an inverted index. A match is declared when many hashes from the sample agree on a single time offset into one track. The offset histogram is the whole trick: noise scatters offsets randomly, a real match stacks them into a spike. ## NetBox Config Templates Tip: Query Objects Efficiently with .filter() DevFeed: [NetBox Config Templates Tip: Query Objects Efficiently with .filter()]() Original publisher: [Read original article]() Author: Rick Donato Published: 2026-03-10T08:00:07Z Content type: tutorial Language: en Sources: [Packet Coders - Learn Network Automation]() Topics: [NetBox](), [Django](), [Object-relational mapping]() Tags: [config](), [django](), [filter](), [interface](), [interfaces](), [netbox](), [orm](), [query](), [templates](), [tips]() ### AI overview A short tutorial showing how to use .filter() in NetBox Config Templates to query objects during lookups and conditional logic through the Django ORM QuerySet interface. ### Source excerpt Use .filter() in Config Templates to query objects during lookups and conditional logic. This exposes the Django ORM QuerySet filter directly in your templates. Here's an example: {% for iface in device.interfaces.filter(enabled=True, name__startswith="ge-") %} interface {{ iface.name }} {% endfor %} ## SQLite Query Optimisation - How the Planner Thinks and Where It Goes Wrong DevFeed: [SQLite Query Optimisation - How the Planner Thinks and Where It Goes Wrong]() Original publisher: [Read original article]() Published: 2026-03-08T00:00:00Z Content type: tutorial Language: en Sources: [Gaurav Sarma's Blog]() Topics: [SQLite](), [SQL](), [Databases]() Tags: [b-tree](), [index](), [optimisation](), [planner](), [query](), [query-planner](), [sql](), [sqlite]() ### AI overview A tutorial on how SQLite's query planner chooses between index searches and full table scans. It explains planner behavior, the effects of query patterns and data distribution, and how to avoid conditions that make indexes inaccessible or scans appear cheaper. ### Source excerpt . [SQLite Query Optimisation](sqlite-query-optimisation-cover... ## pg\_plan\_advice: Plan Stability and User Planner Control for PostgreSQL? DevFeed: [pg\_plan\_advice: Plan Stability and User Planner Control for PostgreSQL?]() Original publisher: [Read original article]() Author: Robert Haas (noreply@blogger.com) Published: 2026-03-04T17:55:00Z Content type: opinion Language: en Sources: [Robert Haas]() Topics: [PostgreSQL](), [JOIN](), [modules](), [Query (disambiguation)]() Tags: [join](), [modules](), [plan](), [planner](), [postgresql](), [query](), [test]() ### AI overview The article presents a proposed PostgreSQL 19 patch set introducing the pg_plan_advice, pg_collect_advice, and pg_stash_advice contrib modules. It demonstrates how pg_plan_advice can generate plan advice strings, preserve selected planner decisions, or vary advice to produce a different join plan. ### Source excerpt I'm proposing a very ambitious patch set for PostgreSQL 19. Only time will tell whether it ends up in the release, but I can't resist using this space to give you a short demonstration of what it can do. The patch set introduces three new contrib modules, currently called pg_plan_advice, pg_collect_advice, and pg_stash_advice. Read more " ## Row Locks With Joins Can Produce Surprising Results in PostgreSQL DevFeed: [Row Locks With Joins Can Produce Surprising Results in PostgreSQL]() Original publisher: [Read original article]() Author: Haki Benita Published: 2026-02-23T22:00:00Z Content type: tutorial Language: en Sources: [Haki Benita]() Topics: [PostgreSQL](), [Concurrency](), [Databases](), [Query (disambiguation)]() Tags: [articles](), [concurrency](), [database](), [locks](), [postgresql](), [query](), [sql]() ### AI overview This article explains a PostgreSQL edge case in which row locks used with joins can produce surprising results, including a query returning no rows despite a valid, enforced foreign key. It uses a concurrent car-ownership update scenario and suggests ways to prevent the issue. ### Source excerpt You execute a query that joins two tables with a valid an enforces foreign key and it returns no results. How is it possible? We thought it wasn't possible, but a recent incident revealed an edge case we never thought about. In this article I show how under some circumstances row locks with joins can produce surprising results, and suggest ways to prevent it. ## Unconventional PostgreSQL Optimizations DevFeed: [Unconventional PostgreSQL Optimizations]() Original publisher: [Read original article]() Author: Haki Benita Published: 2026-01-19T22:00:00Z Content type: tutorial Language: en Sources: [Haki Benita]() Topics: [PostgreSQL](), [Optimization](), [Database](), [Query (disambiguation)](), [Inheritance]() Tags: [articles](), [database-optimization](), [optimization](), [partitioning](), [performance](), [postgresql](), [query](), [vacuum]() ### AI overview This article presents unconventional PostgreSQL optimization techniques. It explains how constraint exclusion can use check constraints to avoid scanning a table for impossible conditions, while noting that enabling it broadly can add planning overhead; partition pruning is enabled by default for partitioned tables. ### Source excerpt When it comes to database optimization, developers often reach for the same old tools: rewrite the query slightly differently, slap an index on a column, denormalize, analyze, vacuum, cluster, repeat. Conventional techniques are effective, but sometimes being creative can really pay off! ## Inside our effort to improve the Mintlify assistant DevFeed: [Inside our effort to improve the Mintlify assistant]() Original publisher: [Read original article]() Author: Patrick Foster Published: 2025-12-12T00:00:00Z Content type: article Language: en Sources: [Mintlify Blog]() Topics: [Artificial Intelligence](), [clickhouse](), [data](), [Large Language Model](), [Software]() Tags: [ai](), [analysis](), [clickhouse](), [customer](), [data](), [engineering](), [llm](), [model](), [pipeline](), [quality](), [query](), [responses](), [script](), [server](), [thread](), [trends]() ### AI overview This article explains how Mintlify analyzed and improved its assistant by rebuilding the feedback pipeline, moving conversation data into ClickHouse, and classifying negative interactions with an LLM. The analysis identified documentation search quality as the assistant's main weakness, while other responses were generally strong. ### Source excerpt A data-driven look at improving the assistant, powered by ClickHouse and deeper feedback analysis. [Next page]()