| From: | Greg Stark <stark(at)mit(dot)edu> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Minmax indexes |
| Date: | 2014-07-10 22:29:17 |
| Message-ID: | CAM-w4HOF8KNPSO7grTL=n83bRe+B+BEpZ5WbAxyP+updbdpNEA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jul 10, 2014 at 10:29 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
>
> What I think should happen is that if the value is changed, the index
> sholud be rebuilt right there.
I disagree. It would be a non-orthogonal interface if ALTER TABLE
sometimes causes the index to be rebuilt and sometimes just makes a
configuration change. I already see a lot of user confusion when some
ALTER TABLE commands rewrite the table and some are quick meta data
changes.
Especially in this case where the type of configuration being changed
is just an internal storage parameter and the user visible shape of
the index is unchanged it would be weird to rebuild the index.
IMHO the "right" thing to do is just to say this parameter is
read-only and have the AM throw an error when the user changes it. But
even that would require an AM callback for the AM to even know about
the change.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2014-07-10 22:38:26 | Re: Pg_upgrade and toast tables bug discovered |
| Previous Message | Jeff Janes | 2014-07-10 22:17:50 | Re: Minmax indexes |