From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Malis <michaelmalis2(at)gmail(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Highly Variable Planning Times |
Date: | 2017-04-19 20:58:38 |
Message-ID: | 30419.1492635518@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Malis <michaelmalis2(at)gmail(dot)com> writes:
> I've been encountering highly variable planning time on PG 9.5.4.
> Running `EXPLAIN SELECT * FROM events_1171738` will take anywhere from
> 200ms to 4s. This likely has to do with the table having 1300 partial
> indexes on it (for reasons elaborated on in
> https://blog.heapanalytics.com/running-10-million-postgresql-indexes-in-production/)
TBH, I see no convincing explanation in that article of why 1300 partial
indexes are a good idea. *At best*, you're doing substantial work in the
planner to avoid the first tree descent step or two in a single
non-partial index. At worst, all your savings go out the window during a
relcache flush, which is likely to happen whenever a vacuum or analyze
gets done on the underlying table.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Malis | 2017-04-19 21:14:54 | Re: Highly Variable Planning Times |
Previous Message | Alvaro Herrera | 2017-04-19 20:49:45 | Re: Highly Variable Planning Times |