| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Oleg Bartunov <obartunov(at)gmail(dot)com>, Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Disabling an index temporarily |
| Date: | 2015-12-14 03:36:01 |
| Message-ID: | CAB7nPqT_k+KqQ2m4x+uQkSsxNV4bCGO7NG3_DTGFnDBGPJVjmg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Dec 14, 2015 at 12:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Certainly, there's opportunities to improve the flexibility of the
> index-disable specifications in the plug-in Oleg and Teodor did. But
> I think that that is the right basic approach: some sort of SET command,
> not anything that alters the catalogs. We already have lots of
> infrastructure that could handle desires like having specific values
> active in only some sessions.
ISTM that an intuitive answer is something like enable_indexscan_list
= 'index1, index2' and not worry about any disable switch, that's more
in line with the equivalent planner-level GUC.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2015-12-14 03:37:41 | Re: Using quicksort for every external sort run |
| Previous Message | Tom Lane | 2015-12-14 03:34:53 | Re: Disabling an index temporarily |