Re: Moving postgresql.conf tunables into 2003...

Список
Период
Сортировка
От Tom Lane
Тема Re: Moving postgresql.conf tunables into 2003...
Дата
Msg-id 10560.1057283855@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Moving postgresql.conf tunables into 2003...  (Sean Chittenden)
Ответы Re: Moving postgresql.conf tunables into 2003...  (Sean Chittenden)
Список pgsql-performance
Дерево обсуждения
Moving postgresql.conf tunables into 2003...  (Sean Chittenden, )
 Re: Moving postgresql.conf tunables into 2003...  (Rod Taylor, )
  Re: Moving postgresql.conf tunables into 2003...  (Sean Chittenden, )
 Re: Moving postgresql.conf tunables into 2003...  ("scott.marlowe", )
  Re: Moving postgresql.conf tunables into 2003...  (Brian Hirt, )
   Re: Moving postgresql.conf tunables into 2003...  (Sean Chittenden, )
    Re: Moving postgresql.conf tunables into 2003...  (Matthew Hixson, )
  Re: Moving postgresql.conf tunables into 2003...  (Sean Chittenden, )
   Re: Moving postgresql.conf tunables into 2003...  (Tom Lane, )
    Re: Moving postgresql.conf tunables into 2003...  (Sean Chittenden, )
 Re: Moving postgresql.conf tunables into 2003...  ("Michael Mattox", )
  Re: Moving postgresql.conf tunables into 2003...  (Sean Chittenden, )
   Re: Moving postgresql.conf tunables into 2003...  (Martin Foster, )
   Re: Moving postgresql.conf tunables into 2003...  (Bruce Momjian, )
 Re: Moving postgresql.conf tunables into 2003...  (Ron, )
 Re: Moving postgresql.conf tunables into 2003...  (Tom Lane, )
  Re: Moving postgresql.conf tunables into 2003...  (Sean Chittenden, )
   Re: Moving postgresql.conf tunables into 2003...  (Rod Taylor, )
   Re: Moving postgresql.conf tunables into 2003...  (Manfred Koizar, )
    Re: Moving postgresql.conf tunables into 2003...  (Sean Chittenden, )
     Re: Moving postgresql.conf tunables into 2003...  (Manfred Koizar, )
      Re: Moving postgresql.conf tunables into 2003...  (Sean Chittenden, )
       Re: Moving postgresql.conf tunables into 2003...  (Tom Lane, )
        Index correlation (was: Moving postgresql.conf tunables into 2003... )  (Manfred Koizar, )
     Use of multipart index with "IN"  (Rob Messer, )
      Re: Use of multipart index with "IN"  (Tom Lane, )
 Re: Moving postgresql.conf tunables into 2003...  (Josh Berkus, )
  Re: Moving postgresql.conf tunables into 2003...  (Tom Lane, )
  Re: Moving postgresql.conf tunables into 2003...  (Tom Lane, )
  Re: Moving postgresql.conf tunables into 2003...  (Tom Lane, )
  Re: Moving postgresql.conf tunables into 2003...  (Sean Chittenden, )
   Re: Moving postgresql.conf tunables into 2003...  (Josh Berkus, )
    Re: Moving postgresql.conf tunables into 2003...  (Sean Chittenden, )
     Re: Moving postgresql.conf tunables into 2003...  (Josh Berkus, )
   Re: Moving postgresql.conf tunables into 2003...  ("Matthew Nuzum", )
    Re: Moving postgresql.conf tunables into 2003...  (Michael Pohl, )
     Re: Moving postgresql.conf tunables into 2003...  (Martin Foster, )
     Re: Moving postgresql.conf tunables into 2003...  (Bruce Momjian, )
    Re: Moving postgresql.conf tunables into 2003...  (Chris Travers, )
     Re: Moving postgresql.conf tunables into 2003...  ("Jim C. Nasby", )
   Re: Moving postgresql.conf tunables into 2003...  (Andrew Sullivan, )
    Re: Moving postgresql.conf tunables into 2003...  ("Matthew Nuzum", )
     Re: Moving postgresql.conf tunables into 2003...  ("Michael Mattox", )
     Re: Moving postgresql.conf tunables into 2003...  (Tom Lane, )
      Re: Moving postgresql.conf tunables into 2003...  (Kaarel, )
       Re: Moving postgresql.conf tunables into 2003...  ("scott.marlowe", )
        Re: Moving postgresql.conf tunables into 2003...  (Martin Foster, )
  Re: Moving postgresql.conf tunables into 2003...  ("Matthew Nuzum", )
Sean Chittenden <> writes:
> Getting the planner to pick
> using the index to filter out data inserted in the last 3 days over
> doing a seq scan...  well, I don't know how you could do that without
> changing the random_page_cost.

This sounds a *whole* lot like a correlation issue.  If the data in
question were scattered randomly in the table, it's likely that an
indexscan would be a loser.  The recently-inserted data is probably
clustered near the end of the table (especially if they're doing VACUUM
FULL after data purges; are they?).  But the planner's correlation stats
are much too crude to recognize that situation, if the rest of the table
is not well-ordered.

If their typical process involves a periodic data purge and then a
VACUUM FULL, it might be worth experimenting with doing a CLUSTER on the
timestamp index instead of the VACUUM FULL.  The CLUSTER would reclaim
space as effectively as VACUUM FULL + REINDEX, and it would leave the
table with an unmistakable 1.0 correlation ... which should tilt the
planner towards an indexscan without needing a physically impossible
random_page_cost to do it.  I think CLUSTER would probably be a little
slower than VACUUM FULL but it's hard to be sure without trying.

            regards, tom lane

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Moving postgresql.conf tunables into 2003...
Следующее
От: Rafal Kedziorski
Дата:
Сообщение: PostgreSQL vs. MySQL