On Jun 26, Chris Wilson modulated:
> I created the index starting with date and it did make a big
> difference: down to 10.3 seconds using a bitmap index scan and bitmap
> heap scan (and then two hash joins as before).
>
By the way, what kind of machine are you using? CPU, RAM, backing
storage?
On Jun 26, Chris Wilson modulated:
> ...
> In your case, the equivalent hack would be to compile the small
> dimension tables into big CASE statements I suppose...
>
>
> Nice idea! I tried this but unfortunately it made the query 16 seconds
> slower (up to 22 seconds) instead of faster.
On Jun 23, Chris Wilson modulated:
> ...
> create table metric_pos (id serial primary key, pos integer);
> create index idx_metric_pos_id_pos on metric_pos (id, pos);
> ...
> create table asset_pos (id serial primary key, pos integer);
> ...
Did you only omit a CREATE INDEX statement o
On May 30, Rick Otten modulated:
> If your clients are keeping persistent connections open to the
> database, and the latency you are experiencing is within the
> transaction itself, you might look at disk I/O for your WAL (write
> ahead logs) and take a closer look at WAL and checkpoint tuning.
>
On Jan 18, Tom Lane modulated:
> Karl Czajkowski writes:
> > Is there a correctness hazard with pretending our function is
> > IMMUTABLE, even though we will change the underlying config parameter
> > in the same connection?
>
> You could probably get away with
On Jan 18, Tom Lane modulated:
> "The same as IMMUTABLE" would be to reduce the function to a constant at
> plan time, which would be the wrong thing. It would be valid to execute
> it only once at query start, but there's no built-in mechanism for that.
>
That's what I was afraid of... right, w
I originally was thinking I had a performance problem related to
row-level security but in reducing it to a simple test case I realized
it applies more generally. The query planner does not seem to
recognize that it can eliminate redundant calls to a STABLE function.
It will optimize the same call
