Re: Alternatives to very large tables with many performance-killing indicies?
В списке pgsql-general по дате отправления:
| От | Jasen Betts |
|---|---|
| Тема | Re: Alternatives to very large tables with many performance-killing indicies? |
| Дата | |
| Msg-id | k0nf8k$5vv$1@reversiblemaps.ath.cx обсуждение исходный текст |
| Ответ на | Alternatives to very large tables with many performance-killing indicies? (Wells Oliver <wellsoliver@gmail.com>) |
| Список | pgsql-general |
On 2012-08-16, Wells Oliver <wellsoliver@gmail.com> wrote: > --0023543336c685451c04c7683ffb > Content-Type: text/plain; charset=ISO-8859-1 > > Hey folks, a question. We have a table that's getting large (6 million rows > right now, but hey, no end in sight). It's wide-ish, too, 98 columns. > > The problem is that each of these columns needs to be searchable quickly at > an application level, and I'm far too responsible an individual to put 98 > indexes on a table. Wondering what you folks have come across in terms of > creative solutions that might be native to postgres. I can build something > that indexes the data and caches it and runs separately from PG, but I > wanted to exhaust all native options first. get rid of some of the columns ? -- ⚂⚃ 100% natural
В списке pgsql-general по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера