Re: Speed of locating tables?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Speed of locating tables?
Дата
Msg-id 2151.959355961@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Speed of locating tables?  (Steve Wampler <swampler@noao.edu>)
Список pgsql-general
Steve Wampler <swampler@noao.edu> writes:
> To me, the most natural way to encode the sets is to
> create a separate table for each set, since the attributes
> can then be indexed and referenced quickly once the table
> is accessed.  But I don't know how fast PG is at locating
> a table, given its name.

> So, to refine the question - given a DB with (say) 100,000
> tables, how quickly can PG access a table given its name?

Don't even think about 100000 separate tables in a database :-(.
It's not so much that PG's own datastructures wouldn't cope,
as that very few Unix filesystems can cope with 100000 files
in a directory.  You'd be killed on directory search times.

I don't see a good reason to be using more than one table for
your attributes --- add one more column to what you were going
to use, to contain an ID for each attribute set, and you'll be
a lot better off.  You'll want to make sure there's an index
on the ID column, of course, or on whichever columns you plan
to search by.

            regards, tom lane

В списке pgsql-general по дате отправления:

Предыдущее
От: Bill Barnes
Дата:
Сообщение: RE: PG 7.0 is 2.5 times slower running a big report
Следующее
От: Steve Wampler
Дата:
Сообщение: Re: Speed of locating tables?