Search
15 results for “indexing”
Search results
PostgreSQL Indexes
How B-Tree, Hash, GIN, BRIN, and covering indexes work in PostgreSQL, when to create them, how to inspect usage, and the write-overhead trade-offs at scale.
How does PostgreSQL decide whether to use an index?
The query planner estimates the cost of each available access path using table statistics (row count, column cardinality, correlation) gathered by ANALYZE. It compares sequential-scan cost against index-scan cost for the specific query. For small tables, or queries that touch a large fraction of rows, a sequential scan often wins even when an index exists, an index is not free to use if it does not narrow the result much. Run EXPLAIN ANALYZE to see the chosen plan, and re-run ANALYZE after large data changes so statistics stay accurate.
What is the difference between a composite index and two separate single-column indexes?
A composite (multi-column) index on (a, b) stores rows sorted by a, then by b within each a. It efficiently serves queries filtering on a alone, or on a and b together, but not on b alone. Two separate single-column indexes let Postgres combine them via a bitmap AND/OR, which works but is usually slower than one well-ordered composite index for the common query pattern. Column order in a composite index should match the most selective, most-frequently-filtered column first.
When would you choose a partial index over a full index?
When queries only ever filter on a subset of rows, for example WHERE is_active = true, or WHERE deleted_at IS NULL. A partial index (CREATE INDEX ... WHERE condition) only stores entries for matching rows, so it is smaller, faster to scan, and cheaper to maintain on writes than indexing the whole table, at the cost of only being usable when the query's WHERE clause matches (or implies) the index condition.
A request's input already exceeds the model's context window before generation even starts. What happens, versus a request that only exceeds the limit once output is generated?
If the input alone already exceeds the context window, the API rejects the request upfront with a 400 error, generation never starts at all. If the input fits but input tokens plus the requested max output tokens could exceed the window, current models accept the request and generate as far as they can; if generation actually reaches the window limit before finishing, it stops early with a specific stop reason indicating the context window was exhausted, rather than silently truncating or erroring out mid-response. The distinction matters operationally: the first case is a fixable request-construction bug, the second is a signal to reduce the requested output length or the accumulated conversation history.
PostgreSQL vs MySQL
How PostgreSQL and MySQL actually differ in data types, concurrency, indexing, and replication, and which one fits which workload.
Why does using an array index as a list item's key cause state to attach to the wrong item once the list is reordered, and what's the fix?
With `key={i}`, React tracks each item's state by its position in the array, not by which real-world item it represents, so after reversing a list, the state that was originally at index 0 (say, an "expanded" toggle on the first item) stays at index 0 and now renders alongside whatever item ended up there after the reorder, not the original item it belonged to. The fix is using a stable, unique identifier from the actual data, `key={contact.id}`, so React can match each item to its correct state across renders regardless of how the list is reordered, added to, or filtered, rather than relying on a position that can shift under the data.
What is an "LLM-graded" eval, and when would you reach for it instead of exact-match or similarity-based grading?
An LLM-graded eval uses a separate model call to judge a subjective quality of the output, tone, empathy, professionalism, on a numeric scale or binary classification, rather than checking it against one fixed correct answer. Exact-match grading only works when there's one right answer (a category label); similarity-based grading (cosine similarity between embeddings) works when wording can vary but meaning should match a reference. LLM-graded evals are the right tool specifically for qualities that are inherently subjective and hard to define with a fixed rule or reference string, at the cost of being noisier and more expensive to run than a simple string comparison.
Azure Policy, Tags, and Resource Locks Explained: A Complete Governance Guide for Cloud Engineers
Effective governance is essential as cloud environments grow. Without proper controls, organizations often face challenges in visibility, accountability, and cost tracking. In this lab, we explore how to implement governance practices in Azure using Azure Policy , Resource Tags , and Resource Locks…
For a sorted list [1, 2, 2, 2, 3], what index does bisect_left(2) return versus bisect_right(2), and why are they different?
`bisect_left` returns 1, the insertion point before every existing 2, so inserting there keeps all 2s together immediately after it. `bisect_right` returns 4, the insertion point after every existing 2, keeping all 2s together immediately before it. They differ because they define the insertion point by a different partition rule, `bisect_left` guarantees everything before the returned index is strictly less than the target, `bisect_right` guarantees everything before the returned index is less than or equal to it, so the choice determines whether a new equal-valued element gets inserted before or after existing equal elements, not just where "some 2" is found.
Name three CSS properties, besides z-index with positioning, that create a new stacking context, and why does that matter when debugging a layering bug?
Opacity below 1, any non-none `transform`, and `filter` or `backdrop-filter` with a value other than `none` all create a new stacking context, along with several others like `isolation: isolate` and `will-change` naming a stacking-context property. This matters when debugging because a completely unrelated-looking style change, adding a fade transition via opacity, or a hover effect via transform, can silently create a new stacking context and change how that element's children layer against the rest of the page, a z-index layering bug that has nothing to do with z-index values themselves, but with an accidental new stacking context somewhere in the ancestor chain.
What does hashed sharding trade away in exchange for fixing the monotonic-key hot-shard problem?
Hashed sharding computes a hash of the shard key value and assigns chunks by hash range instead of by the raw value, which scatters even monotonically increasing keys roughly evenly across shards, since consecutive input values hash to essentially unrelated output values. The trade-off is range-query locality: a query filtering a range of the original shard key values (like "the last 24 hours" on a timestamp key) can no longer be routed to one contiguous set of shards, because the corresponding hashed values are scattered unpredictably across the whole cluster, turning what would have been a single-shard query under range sharding into a broadcast query touching every shard.
Microsoft Entra Conditional Access Explained: MFA, Location Controls, and the What If Tool (Full Lab Guide)
How Conditional Access Evaluates Sign‑Ins Behind the Scenes
Two transactions each update two of the same two accounts, but in opposite order, and deadlock. What's the actual fix, not just for this pair of transactions, but for the application generally?
The deadlock happens because Transaction 1 locks account A then waits for account B, while Transaction 2 locks account B then waits for account A, a circular wait. The general fix isn't retry logic alone, retries only paper over deadlocks that keep recurring, it's acquiring locks on multiple objects in the same, consistent order everywhere in the application (for example, always locking accounts in ascending id order), which makes the circular-wait pattern structurally impossible rather than merely less frequent. Retry logic is still worth having as a safety net, but consistent lock ordering is what actually eliminates this class of deadlock.
What does box-sizing: border-box actually change about how width and height are calculated?
With the default `content-box`, `width` applies only to the content area, so padding and border are added on top, a 200px-wide box with 20px padding and a 5px border renders at 250px total. `border-box` makes `width` include content, padding, and border together, so that same 200px `width` stays 200px total regardless of padding or border, the content area itself shrinks to make room instead. This is why most modern projects apply `box-sizing: border-box` globally, it makes an element's declared width predictable and stable as padding/border change, instead of recalculating the total size by hand every time.