Re: [GENERAL] Different query plan used for the same query dependingon how parameters are passed

Поиск
Список
Период
Сортировка
От Igor Neyman
Тема Re: [GENERAL] Different query plan used for the same query dependingon how parameters are passed
Дата
Msg-id DM5PR07MB28102EE99E221E5D54359B7EDAE60@DM5PR07MB2810.namprd07.prod.outlook.com
обсуждение исходный текст
Ответ на [GENERAL] Different query plan used for the same query depending on howparameters are passed  (David Chapman <david.chapman@mavensecurities.com>)
Список pgsql-general

From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of David Chapman
Sent: Tuesday, May 16, 2017 9:02 AM
To: pgsql-general@postgresql.org
Subject: [GENERAL] Different query plan used for the same query depending on how parameters are passed

 

Attention: This email was sent from someone outside of Perceptron. Always exercise caution when opening attachments or clicking links from unknown senders or when receiving unexpected emails.

 

I have a table that includes two text columns t1 and t2, and a composite index on these columns. When issuing a query of the following form:

 

SELECT * FROM test WHERE t1 = 'X' and t2 = ANY(ARRAY['Y1', 'Y2', ..])

 

I have observed that it will use the index and have reasonable performance if the whole query is passed as a single big string. However if it is parameterised (I'm using Npgsql) it switches to doing a sequence scan and performs terribly.

 

The table contains approx 2.3 million records and the query matches about 20k records (i.e. there are 20k 'Y' values in the array).

 

I have experimented with changing work_mem, preparing the statement in advance, ANALYZEing the table, none of these change the behavior.

 

Why does the query planner choose to ignore the index when the command is parameterised? 

 

It’s because when optimizer builds execution plan for parametrized queiry, it doesn’t know what values for t1 and t2 will be provided for WHERE clause.

Regards,

Igor Neyman

 

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

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: [GENERAL] storing large files in database - performance
Следующее
От: John R Pierce
Дата:
Сообщение: Re: [GENERAL] storing large files in database - performance