Re: how to improve perf of 131MM row table?

Поиск
Список
Период
Сортировка
От Sébastien Lorion
Тема Re: how to improve perf of 131MM row table?
Дата
Msg-id CAGa5y0PAnzz5jPTr=PsUUwZ2dWQ0Oz_XZnM0bszGOMHVFzEYwg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: how to improve perf of 131MM row table?  (Shaun Thomas <sthomas@optionshouse.com>)
Список pgsql-performance
On Thu, Jun 26, 2014 at 10:37 AM, Shaun Thomas <sthomas@optionshouse.com> wrote:
On 06/26/2014 09:22 AM, AJ Weber wrote:

I sent the details as identified by pgAdmin III.

Interesting. Either there is a bug in pgAdmin, or you're connecting to a different database that is missing the primary key. What is the EXPLAIN ANALYZE output if you execute the query you sent on a psql prompt?


     "alf_node_pkey" PRIMARY KEY, btree (id) CLUSTER
would indicate to me that there is a PK on alf_node table, it is on
column "id", it is of type btree, and the table is clustered around that
index.

Am I reading this totally wrong?

No, that's right. But that wasn't in the SQL you sent. In fact, there's a lot of stuff missing in that output.

Try running the EXPLAIN ANALYZE using the same psql connection you used to retrieve the actual table structure just now. I suspect you've accidentally connected to the wrong database. If it's still doing the sequence scan, we'll have to dig deeper.
 

​I see "CONSTRAINT alf_node_pkey PRIMARY KEY (id)" for table1 and ​"CONSTRAINT alf_node_properties_pkey PRIMARY KEY (node_id, qname_id, list_index, locale_id)" for table2. When you say there is not primary key defined, is it based on the execution plan ?

Sébastien

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

Предыдущее
От: Shaun Thomas
Дата:
Сообщение: Re: how to improve perf of 131MM row table?
Следующее
От: AJ Weber
Дата:
Сообщение: Re: how to improve perf of 131MM row table?