Re: What is the right way to deal with a table with rows that are not in a random order?
В списке pgsql-general по дате отправления:
| От | Scott Marlowe |
|---|---|
| Тема | Re: What is the right way to deal with a table with rows that are not in a random order? |
| Дата | |
| Msg-id | dcc563d10905281247w199ca85an2baf7c06b2109491@mail.gmail.com обсуждение |
| Ответ на | Re: What is the right way to deal with a table with rows that are not in a random order? (Douglas Alan <darkwater42@gmail.com>) |
| Список | pgsql-general |
On Thu, May 28, 2009 at 1:12 PM, Douglas Alan <darkwater42@gmail.com> wrote: > On Thu, May 28, 2009 at 10:24 AM, Scott Marlowe <scott.marlowe@gmail.com> wrote: > >> OTOH, if you've got it all sussed out, then ignore the request for more information. > > I don't *know* if I have it "all sussed out", but I *do* know why > Postgres is doing what it is doing in this particular case. It's > assuming that the value in question is evenly distributed throughout > the table, when in actuality, the value in question is clustered at > the very end of the table. It's doing way more than that. My point above was that the query planner is not JUST assuming the values are wel ordered. It's assuming random_page_cost is x times more than sequential page cost, it's assuming the table doesn't fit in effective cache, or shared buffers, it's assuming lots of things based on how you've tuned (or not) your database. I'll finish in reply to your other post.
В списке pgsql-general по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера