From: | Jerry Sievers <gsievers19(at)comcast(dot)net> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | "Campbell\, Lance" <lance(at)illinois(dot)edu>, "pgsql-admin\(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: pg_restore new parameter request |
Date: | 2015-11-23 17:37:45 |
Message-ID: | 86fuzwaa6u.fsf@jerry.enova.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Mon, Nov 23, 2015 at 7:37 AM, Campbell, Lance <lance(at)illinois(dot)edu> wrote:
>
> Without the indexes the production system would run slower until they were applied but at least I would be up and running.
>
> âAt least until excessive sequential scanning overloads the I/O subsystem and you max out your processes, connections and/or timeouts...
>
> I'd be curious to know if you've ever tried dropping all of your indexes and running your systems under somewhat realistic load levels.
Agreed. Unless the OPs app/DB are either tiny and utterly trivial or
the app that they're in a hurry to get online again is something that
just inserts data, then the notion of omitting all indexes is rather
far-fetched and I bet not too generally useful.
I can certainly imagine a scenario where there are very large tables
which have some indexes created just to support reporting/analytics
workloads which perhaps could be deferred in building till after most
other application aspects are running.
In such a case, then you'd want just to omit and/or reorder building
those after everything else.
FWIW
> David J.
> â
> Â
>
--
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres(dot)consulting(at)comcast(dot)net
p: 312.241.7800
From | Date | Subject | |
---|---|---|---|
Next Message | John Scalia | 2015-11-23 19:57:51 | Weird query error from one of my users |
Previous Message | David G. Johnston | 2015-11-23 14:55:06 | Re: pg_restore new parameter request |