Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
Date
Msg-id 15187.1581691360@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: [HACKERS] Moving relation extension locks out of heavyweightlock manager
Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
List pgsql-hackers
Amit Kapila <amit.kapila16@gmail.com> writes:
> I think MaxBackends will generally limit the number of different
> relations that can simultaneously extend, but maybe tables with many
> partitions might change the situation.  You are right that some tests
> might suggest a good number, let Mahendra write a patch and then we
> can test it.  Do you have any better idea?

In the first place, there certainly isn't more than one extension
happening at a time per backend, else the entire premise of this
thread is wrong.  Handwaving about partitions won't change that.

In the second place, it's ludicrous to expect that the underlying
platform/filesystem can support an infinite number of concurrent
file-extension operations.  At some level (e.g. where disk blocks
are handed out, or where a record of the operation is written to
a filesystem journal) it's quite likely that things are bottlenecked
down to *one* such operation at a time per filesystem.  So I'm not
that concerned about occasional false-sharing limiting our ability
to issue concurrent requests.  There are probably worse restrictions
at lower levels.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: assert pg_class.relnatts is consistent
Next
From: Robert Haas
Date:
Subject: Re: Wait event that should be reported while waiting for WALarchiving to finish