Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance
Дата
Msg-id dcc563d10904060822v3d9ce49fy359c9f9753034f19@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance  (Mario Splivalo <mario.splivalo@megafon.hr>)
Список pgsql-performance
On Mon, Apr 6, 2009 at 8:50 AM, Mario Splivalo
<mario.splivalo@megafon.hr> wrote:
> Scott Marlowe wrote:
>>>
>>> CREATE INDEX photo_info_data_ix_field_value
>>>  ON user_info_data USING btree (field_value);
>>>
>>> So, there is index on (user_id, field_name). Postgres is using index for
>>> user_id (...WHERE user_id = 12345) but not on field-name (...WHERE
>>> field_name = 'f-spot'). When I add extra index on field name:
>>>
>>> CREATE INDEX photo_info_data_ix__field_name
>>>  ON user_info_data USING btree (field_name);
>>>
>>> Then that index is used.
>>
>> On older versions of pgsql, the second of two terms in a multicolumn
>> index can't be used alone.  On newer versions it can, but it is much
>> less efficient than if it's a single column index or if the term is
>> the first one not the second.
>
> I'm using 8.3.7. So, you'd also suggest to keep that extra (in a way
> redundant) index on field_name, since I need PK on (photo_id, field_name) ?

Either that or reverse the terms in the pk.

Also, you might want to look at adjusting random_page_access to
something around 1.5 to 2.0.

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

Предыдущее
От: Mario Splivalo
Дата:
Сообщение: Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance
Следующее
От: Lists
Дата:
Сообщение: Re: Best replication solution?