From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Jehan-Guillaume (ioguix) de Rorthais" <ioguix(at)free(dot)fr> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Lock issues with partitioned table |
Date: | 2010-06-03 14:00:23 |
Message-ID: | 24014.1275573623@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Jehan-Guillaume (ioguix) de Rorthais" <ioguix(at)free(dot)fr> writes:
> Shouldn't locks only be on tables/indexes that are actually used by the
> planner ?
Well, yeah, they are. The planner must take at least AccessShareLock
on any relation referenced by the query. It might later be able to
prove that the relation needn't be scanned to deliver the query answer,
but it first has to lock the relation enough to examine its constraints
before it can prove that. Similarly, indexes get locked for the purpose
of inspecting them, whether or not they actually get selected for use in
the plan.
AccessShareLock is a weak enough lock that this generally isn't a
problem; all that it's doing is ensuring that the table's schema
doesn't change while we're trying to devise a plan.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-06-03 14:28:03 | Re: so, does this overlap or not...? - fencepost question on overlaps() |
Previous Message | Max Williams | 2010-06-03 13:22:29 | Performance drop after upgrading to 8.4.4? |