Tim Slechta writes:
> Why does the planner not use an index when a view is involved?
It's not about a "view" ... you'd get the same results if you wrote
out the UNION ALL construct in-line as a sub-select.
I think you may be shooting yourself in the foot by not making sure that
the UNION ALL arm
On Wed, Oct 27, 2021 at 7:31 PM Tim Slechta wrote:
>
> == Point 2. The equivalent query on the VL10N_OBJECT_NAME view executes a
> Seq Scan on the underlying pl10n_object_name. Why?
> tc=# EXPLAIN ANALYZE select pval_0 from VL10N_OBJECT_NAME where pval_0 =
> '';
>
Just to confirm and simplif
Why does the planner not use an index when a view is involved?
1) A description of what you are trying to achieve and what results you
expect.
Why don't plans use indexes when views are involved? A similar query on
the underlying table leverages the appropriate index.
== Point 1. The following q
Hi,
On October 27, 2021 2:44:56 PM PDT, Ashkil Dighin
wrote:
>Hi,
>Yes, lock contention reduced with postgresqlv14.
>Lock acquire reduced 18% to 10%
>10.49 %postgres postgres[.] LWLockAcquire
>5.09% postgres postgres[.] _bt_compare
>
>Is lock contention can be reduced
On Fri, Sep 24, 2021 at 5:02 PM Tim wrote:
> I'm currently doing this with a 2.2 TB database.
>
> Best way IMO is to (UPDATE pg_index SET indisready = false ... ) for non
> PK indexes for the largest tables. Then just set it back to indisready =
> true after its done and run a REINDEX CONCURRENTL
