| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, James Coleman <jtc331(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Subject: | Re: PROC_IN_ANALYZE stillborn 13 years ago |
| Date: | 2020-08-06 18:25:27 |
| Message-ID: | CA+TgmoZn5oX4j3KXMkQx=RN+QBgc_y3+1LjBcy_afOmJb-f0-A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Aug 5, 2020 at 9:07 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> I'm mildly against that, because I'd really like to start making use of
> the flag. Not so much for cancellations, but to avoid the drastic impact
> analyze has on bloat. In OLTP workloads with big tables, and without
> disabled cost limiting for analyze (or slow IO), the snapshot that
> analyze holds is often by far the transaction with the oldest xmin.
>
> It's not entirely trivial to fix (just ignoring it could lead to
> detoasting issues), but also not that.
>
> Only mildly against because it'd not be hard to reintroduce once we need
> it.
I think we should nuke it. It's trivial to reintroduce the flag if we
need it later, if and when somebody's willing to do the associated
work. In the meantime, it adds confusion.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-08-06 18:37:38 | Re: PROC_IN_ANALYZE stillborn 13 years ago |
| Previous Message | Robert Haas | 2020-08-06 18:21:01 | Re: Issue with cancel_before_shmem_exit while searching to remove a particular registered exit callbacks |