| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, John Naylor <john(dot)naylor(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Unhappy about API changes in the no-fsm-for-small-rels patch |
| Date: | 2019-05-06 16:16:44 |
| Message-ID: | CA+TgmoaOkfMYu7qd6_sXuTzBZHycvw_a=fw080GFFyoHXPiHEQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, May 6, 2019 at 12:05 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > ... I guess you could incur the overhead repeatedly if the relation starts
> > out at 1 block, grows to 4, is vacuumed back down to 1, lather, rinse,
> > repeat, but is that actually realistic?
>
> While I've not studied the patch, I assumed that once a relation has an
> FSM it won't disappear. Making it go away again if the relation gets
> shorter seems both fairly useless and a promising source of bugs.
Right, I think so too. That's not what I as going for, though. I was
trying to discuss a scenario where the relation repeatedly grows,
never reaching the size at which the FSM would be created, and then is
repeatedly truncated again.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2019-05-06 16:18:18 | Re: Unhappy about API changes in the no-fsm-for-small-rels patch |
| Previous Message | Robert Haas | 2019-05-06 16:14:55 | Re: Fixing order of resowner cleanup in 12, for Windows |