On 2022-Aug-19, David Geier wrote:
> Beyond that I did some off-CPU profiling to precisely track down which lock
> serializes execution. It turned out to be the MyProc::fpInfoLock lightweight
> lock. This lock is used in the fast path of the heavyweight lock. In the
> contenting case, fpInfoLock
On 8/1/22 15:33, David Geier wrote:
Hi Tom,
On Wed, Jul 27, 2022 at 7:15 PM Tom Lane wrote:
I wrote:
> Unfortunately, as things stand today, the planner needs more
than the
> right to look at the indexes' schemas, because it makes physical
accesses
> to btree indexes
On 27.07.22, 18:39, "Tom Lane" wrote:
[External Email]
David Geier writes:
> We tracked down the root cause of this slowdown to lock contention in
> 'get_relation_info()'. The index lock of every single index of every
single
> table used in that query is acquired. We
Hi Tom,
On Wed, Jul 27, 2022 at 6:39 PM Tom Lane wrote:
> David Geier writes:
> > We tracked down the root cause of this slowdown to lock contention in
> > 'get_relation_info()'. The index lock of every single index of every
> single
> > table used in that query is acquired. We attempted a fix
Hi Tom,
On Wed, Jul 27, 2022 at 7:15 PM Tom Lane wrote:
> I wrote:
> > Unfortunately, as things stand today, the planner needs more than the
> > right to look at the indexes' schemas, because it makes physical accesses
> > to btree indexes to find out their tree height (and I think there are
>
I wrote:
> Unfortunately, as things stand today, the planner needs more than the
> right to look at the indexes' schemas, because it makes physical accesses
> to btree indexes to find out their tree height (and I think there are some
> comparable behaviors in other AMs). I've never particularly
David Geier writes:
> We tracked down the root cause of this slowdown to lock contention in
> 'get_relation_info()'. The index lock of every single index of every single
> table used in that query is acquired. We attempted a fix by pre-filtering
> out all indexes that anyways cannot be used with
Sorry, by accident I sent this one out twice.
--
David Geier
(ServiceNow)
On Wed, Jul 27, 2022 at 2:42 PM David Geier wrote:
> Hi hackers,
>
> We came across a slowdown in planning, where queries use tables with many
> indexes. In setups with wide tables it is not uncommon to have easily
>
Hi hackers,
We came across a slowdown in planning, where queries use tables with many
indexes. In setups with wide tables it is not uncommon to have easily
10-100 indexes on a single table. The slowdown is already visible in serial
workloads with just a handful of indexes, but gets drastically
Hi hackers,
We came across a slowdown in planning, where queries use tables with many
indexes. In setups with wide tables it is not uncommon to have easily
10-100 indexes on a single table. The slowdown is already visible in serial
workloads with just a handful of indexes, but gets drastically
10 matches
Mail list logo
