Re: Inefficient query plan

Поиск
Список
Период
Сортировка
От Grzegorz Jaśkiewicz
Тема Re: Inefficient query plan
Дата
Msg-id AANLkTim1GOMuN+EzEj9CcePUHQ=71uLhF=Dn3p1n3tpE@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Inefficient query plan  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: Inefficient query plan  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список pgsql-performance
I am not a fan of 'do this - this is best' response to queries like that.
Rather: this is what you should try, and choose whichever one suits you better.
So, rather than 'natural keys ftw', I am giving him another option to
choose from.

You see, in my world, I was able to improve some large dbs performance
10+ times fold, by going for surrogate keys. But in them cases, joins
were performed on 2+ varchar PK fields, and the whole thing was
crawwwling.

So, don't narrow down to one solution because it worked for you. Keep
an open book.

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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Inefficient query plan
Следующее
От: Grzegorz Jaśkiewicz
Дата:
Сообщение: Re: Inefficient query plan