2012/3/21 Tom Lane t...@sss.pgh.pa.us
BTW, I experimented with that a little bit and found that the relmapper
is not really the stumbling block, at least not after applying this
one-line patch:
=?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= fabriziome...@gmail.com writes:
2012/3/21 Tom Lane t...@sss.pgh.pa.us
BTW, I experimented with that a little bit and found that the relmapper
is not really the stumbling block, at least not after applying this
one-line patch:
Thanks for the tips. I spent some more time investigating. It's
definitely pg_table_is_visible that's causing the problem. A \dt
schema.* is fairly fast (like you said, it doesn't apply
pg_table_is_visible at all). I tried adjusting the query in several
ways. Adding either
Cody Cutrer c...@instructure.com writes:
On Tue, Mar 20, 2012 at 6:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
There's not really support for adding indexes to system catalogs
on-the-fly. I think it would work (barring concurrency issues)
for most catalogs, but pg_class has special limitations
That's awesome, thanks! Yeah, I doubt I'll do that to our production
database, but maybe I'll try it on a copy sometime down the line.
Adjusting the cost for pg_table_is_visible is working well enough so
far.
Cody Cutrer
On Wed, Mar 21, 2012 at 12:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Cody
I've got a SaaS situation where I'm using 1000+ schemas in a single
database (each schema contains the same tables, just different data
per tenant). I used schemas so that the shared app servers could
share a connection to the single database for all schemas. Things are
working fine. However,
Cody Cutrer c...@instructure.com writes:
I've got a SaaS situation where I'm using 1000+ schemas in a single
database (each schema contains the same tables, just different data
per tenant). ...
if I add nspname = ANY(current_schemas(true)) to the query psql is
using, and an index to pg_class
