1"use strict";(self.webpackChunkdatabase_lab_docs=self.webpackChunkdatabase_lab_docs||[]).push([["32138"],{66571(e,t,a){a.r(t),a.d(t,{assets:()=>l,contentTitle:()=>i,default:()=>d,frontMatter:()=>o,metadata:()=>n,toc:()=>p});var n=a(22175),s=a(74848),r=a(28453);let o={title:"#PostgresMarathon 2-010: Prepared statements and partitioned table lock explosion, part 2",date:new Date("2025-10-29T23:59:59.000Z"),authors:"nik",tags:["Postgres insights","PostgresMarathon","internals","locks","lockmanager","prepared statements","partitioning"]},i,l={authorsImageUrls:[void 0]},p=[];function g(e){let t={a:"a",li:"li",p:"p",ul:"ul",...(0,r.R)(),...e.components};return(0,s.jsxs)(s.Fragment,{children:[(0,s.jsxs)(t.p,{children:["In ",(0,s.jsx)(t.a,{href:"https://postgres.ai/blog/20251028-postgres-marathon-2-009",children:"#PostgresMarathon 2-009"}),", we focused on Lock Manager's behavior when dealing with prepared statements and partitioned tables."]}),"\n",(0,s.jsx)(t.p,{children:"And observed a lock explosion in our simple synthetic example: from 8 locks (custom plans) during first 5 calls, to 52 locks (building generic plan) in the 6th call, to 13 locks (using cached generic plan) in the 7th and subsequent calls. We left with questions:"}),"\n",(0,s.jsxs)(t.ul,{children:["\n",(0,s.jsx)(t.li,{children:"this lock explosion at the 6th call \u2013 why is it so exactly and can it be avoided?"}),"\n",(0,s.jsx)(t.li,{children:"why do we lock all 12 partitions even though runtime pruning removes 11 of them?"}),"\n"]}),"\n",(0,s.jsx)(t.p,{children:"Let's dig deeper."})]})}function d(e={}){let{wrapper:t}={...(0,r.R)(),...e.components};return t?(0,s.jsx)(t,{...e,children:(0,s.jsx)(g,{...e})}):g(e)}},28453(e,t,a){a.d(t,{R:()=>o,x:()=>i});var n=a(96540);let s={},r=n.createContext(s);function o(e){let t=n.useContext(r);return n.useMemo(function(){return"function"==typeof e?e(t):{...t,...e}},[t,e])}function i(e){let t;return t=e.disableParentContext?"function"==typeof e.components?e.components(s):e.components||s:o(e.components),n.createElement(r.Provider,{value:t},e.children)}},22175(e){e.exports=JSON.parse('{"permalink":"/blog/20251029-postgres-marathon-2-010","editUrl":"https://gitlab.com/postgres-ai/docs/-/edit/master/blog/20251029-postgres-marathon-2-010.md","source":"@site/blog/20251029-postgres-marathon-2-010.md","title":"#PostgresMarathon 2-010: Prepared statements and partitioned table lock explosion, part 2","description":"In #PostgresMarathon 2-009, we focused on Lock Manager\'s behavior when dealing with prepared statements and partitioned tables.","date":"2025-10-29T23:59:59.000Z","tags":[{"inline":true,"label":"Postgres insights","permalink":"/blog/tags/postgres-insights"},{"inline":true,"label":"PostgresMarathon","permalink":"/blog/tags/postgres-marathon"},{"inline":true,"label":"internals","permalink":"/blog/tags/internals"},{"inline":true,"label":"locks","permalink":"/blog/tags/locks"},{"inline":true,"label":"lockmanager","permalink":"/blog/tags/lockmanager"},{"inline":true,"label":"prepared statements","permalink":"/blog/tags/prepared-statements"},{"inline":true,"label":"partitioning","permalink":"/blog/tags/partitioning"}],"readingTime":3.2,"hasTruncateMarker":true,"authors":[{"name":"Nikolay Samokhvalov","title":"CEO & Founder","email":"[email protected]","imageURL":"/assets/author/nik.jpg","key":"nik","page":null}],"frontMatter":{"title":"#PostgresMarathon 2-010: Prepared statements and partitioned table lock explosion, part 2","date":"2025-10-29T23:59:59.000Z","authors":"nik","tags":["Postgres insights","PostgresMarathon","internals","locks","lockmanager","prepared statements","partitioning"]},"unlisted":false,"prevItem":{"title":"#PostgresMarathon 2-011: Prepared statements and partitioned tables \u2014 the paradox, part 3","permalink":"/blog/20251030-postgres-marathon-2-011"},"nextItem":{"title":"#PostgresMarathon 2-009: Prepared statements and partitioned table lock explosion, part 1","permalink":"/blog/20251028-postgres-marathon-2-009"}}')}}]);
Line numbers count LF bytes from the start of the resource, as the search results do. Vendor segments are library code the classifier recognised; they are stored but not indexed. Bytes are shown as Latin1 characters, one per byte.