Re: how to improve perf of 131MM row table?
От | AJ Weber |
---|---|
Тема | Re: how to improve perf of 131MM row table? |
Дата | |
Msg-id | 53AC40CB.9020006@comcast.net обсуждение исходный текст |
Ответ на | Re: how to improve perf of 131MM row table? (AJ Weber <aweber@comcast.net>) |
Ответы |
Re: how to improve perf of 131MM row table?
|
Список | pgsql-performance |
FWIW: I tested removing the quotes around each value, and it did not change the plan (I am a little surprised too, but I guess PG is "smarter than that"). Thanks for the idea. On 6/26/2014 11:38 AM, AJ Weber wrote: > I noticed this too. I am trying to find where the actual SQL is > generated, and I am seeing if this is an artifact of Hibernate. > > Will test the same query without the quotes as you recommend. (But I > don't know where to fix that, if it is the actual issue, unfortunately.) > > On 6/26/2014 11:35 AM, Claudio Freire wrote: >> On Thu, Jun 26, 2014 at 10:26 AM, AJ Weber <aweber@comcast.net> wrote: >>> OK, the sample query is attached (hopefully attachments are allowed) as >>> "query.sql". >>> The "master table" definition is attached as "table1.sql". >>> The "detail table" definition is attached as "table2.sql". >>> The EXPLAIN (ANALYZE, BUFFERS) output is here: >>> http://explain.depesz.com/s/vd5 >> >> I think the problem is that you're sending strings in the ids, instead >> of integers. >> >> Remove the quotes, leave only the numbers. That will make pg able to >> infer that node.id = prop.node_id means it can also use an index on >> alf_node_properties. >> >> I think. >> >> Try. > > >
В списке pgsql-performance по дате отправления: