On Wed, 4 May 2022 at 06:11, Levi Aul wrote:
> It is our expectation that this query “should” be able to be cheap-to-compute
> and effectively instantaneous. (It’s clear to us how we would make it so,
> given a simple LMDB-like sorted key-value store: prefix-match on
> holder_address; take the
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) without time zone NOT NULL,
contract_address bytea NOT NULL
On Wed, 4 May 2022 at 00:21, Benjamin Coutu wrote:
> Thanks David, using extended statistics for both (and only for both) tables
> solved this problem.
Oh, whoops. I did get that backwards. The estimate used by the
Memoize costing code is from the outer side of the join, which is the
extdataemp
> I'd say it's a pretty different problem. The cache hit ratio
> discussion on that thread talks about underestimating the hit ratio.
> That particular problem could only lead to Memoize plans *not* being
> chosen when they maybe should be. Not the other way around, which is
> your case.
>
> creat
On Tue, 3 May 2022 at 23:05, Benjamin Coutu wrote:
> -> Memoize (cost=0.58..0.67 rows=1 width=16) (actual time=0.002..0.002
> rows=0 loops=4067215)
> Cache Key: e2.field, e2.index
> Cache Mode: logical
> Hits: 0 Misses: 4067215 Evictions: 3228355 Overflows: 0 Memor
Hello,
I have come across a plan that should never get generated IMHO:
SELECT 1
FROM extdataregular e1
INNER JOIN extdataempty e2 ON e1.field = e2.field AND e1.index = e2.index
generates the following plan:
Nested Loop (cost=1.13..528540.89 rows=607604 width=4) (actual
time=9298.504..9298.506
