Re: Inefficient query plan

Поиск
Список
Период
Сортировка
Искать
От
Kevin Grittner
Тема
Re: Inefficient query plan
Дата
Msg-id
4C72359D0200002500034A4D@gw.wicourts.gov
Ответ на
Re: Inefficient query plan (Grzegorz Jaśkiewicz)
Список
Дерево обсуждения
Inefficient query plan Jann Röder <roederja@ethz.ch>
Re: Inefficient query plan Alvaro Herrera <alvherre@commandprompt.com>
Re: Inefficient query plan Tom Lane <tgl@sss.pgh.pa.us>
Re: Inefficient query plan Scott Marlowe <scott.marlowe@gmail.com>
Re: Inefficient query plan Scott Marlowe <scott.marlowe@gmail.com>
Re: Inefficient query plan Jann Röder <roederja@ethz.ch>
Re: Inefficient query plan Scott Marlowe <scott.marlowe@gmail.com>
Re: Inefficient query plan Jann Röder <roederja@ethz.ch>
Grzegorz Jaœkiewicz wrote:
 
> joining on varchars is always going to be very expensive. Longer
> the value is, more expensive it will be. Consider going for
> surrogate keys.
 
Surrogate keys come with their own set of costs and introduce quite
a few problems of their own.  I don't want to start a flame war or
go into an overly long diatribe on the evils of surrogate keys on
this thread; suffice it to say that it's not the first thing to try
here.
 
As an example of the performance we get using natural keys, with
compound keys on almost every table, check out this 1.3TB database,
being updated live by 3000 users as you view it:
 
http://wcca.wicourts.gov/
 
Some tables have hundreds of millions of rows.  No partitioning.
 
-Kevin
В списке pgsql-performance по дате отправления
От: Kevin Grittner
Дата:
Сообщение: Re: Inefficient query plan
От: Grzegorz Jaśkiewicz
Дата:
Сообщение: Re: Inefficient query plan
FAQ