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?  (Claudio Freire <klaussfreire@gmail.com>)
Список 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 по дате отправления:

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