=?UTF-8?Q?Andr=C3=A9_H=C3=A4nsel?= writes:
> Limit (cost=0.43..296.63 rows=50 width=4) (actual time=1052.692..1052.737
> rows=50 loops=1)
> -> Index Scan using orders_test_pkey on orders_test (cost=0.43..71149.43
> rows=12010 width=4) (actual time=1052.690..1052.728 rows=50 loops=1)
>
> They are sorted by order_id only within sets of the same shipping_date, which
> is not good enough.
Ah yes, that totally makes sense for the general case.
> so maybe you can just tweak that application to test if the start and end
> dates are the same and use equality when they are.
I defi
On Thu, 5 May 2022 at 11:15, André Hänsel wrote:
>
> Quick(?) question... why is there a Sort node after an Index Only Scan?
> Shouldn't the index already spit out sorted tuples?
>
> CREATE INDEX ON orders_test(shipping_date, order_id);
>
> EXPLAIN ANALYZE SELECT
> FROM orders_test
> WHERE TRUE
>
On Wed, May 4, 2022 at 7:15 PM André Hänsel wrote:
> Quick(?) question... why is there a Sort node after an Index Only Scan?
> Shouldn't the index already spit out sorted tuples?
>
> CREATE INDEX ON orders_test(shipping_date, order_id);
>
> EXPLAIN ANALYZE SELECT
> FROM orders_test
> WHERE TRUE
>
Quick(?) question... why is there a Sort node after an Index Only Scan?
Shouldn't the index already spit out sorted tuples?
CREATE INDEX ON orders_test(shipping_date, order_id);
EXPLAIN ANALYZE SELECT
FROM orders_test
WHERE TRUE
AND shipping_date >= '2022-05-01'
AND shipping_date <= '2022-05-01'
On Tue, May 3, 2022 at 2:11 PM Levi Aul wrote:
> I have a “temporal table” — a table where there are multiple “versions” of
> entities, with each version having a distinct timestamp:
> CREATE TABLE contract_balance_updates (
> block_id bigint NOT NULL,
> block_signed_at timestamp(0) witho
