| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Simon Riggs" <simon(at)2ndQuadrant(dot)com>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "decibel" <decibel(at)decibel(dot)org>, "Itagaki Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: FSM search modes |
| Date: | 2009-10-01 20:47:59 |
| Message-ID: | 3969.1254430079@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> The way I figure it, if there is a 0.01 chance to reset the sweep,
> then there's a 0.99 percent chance to continue the sweep from the last
> position. 0.99^229 is about 0.1, which means there is a 10% chance
> not to have reset after that many attempts to advance.
Right, so the odds would be that a backend will confine its insertion
attempts to the first 229 pages containing a usable amount of free
space. As long as the number of backends concurrently inserting
into the relation is well under 229, this seems perfectly fine.
(Hm, so we might want to make the probability depend on
max_connections?)
A possible downside of keeping things compact this way is that you'd
probably get a longer average search distance because of all the early
pages tending to remain full. Maybe what we want is some bias against
inserting in the last half or quarter of the table, or some such rule,
rather than necessarily heading for the start of the relation.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bernd Helmle | 2009-10-01 21:07:32 | Re: TODO item: Allow more complex user/database default GUC settings |
| Previous Message | Robert Haas | 2009-10-01 20:46:26 | Re: FSM search modes |