Re: ERROR: ORDER/GROUP BY expression not found in targetlist

Поиск

Список

Период

Сортировка

От	Amit Kapila
Тема	Re: ERROR: ORDER/GROUP BY expression not found in targetlist
Дата	14 июня 2016 г. 18:33:21
Msg-id	CA+kptmAU4xkzBpd8tie3X6o9_tE2oKm-0kDn8+ZOF=2_qOMZNA@mail.gmail.com обсуждение исходный текст
Ответ на	Re: ERROR: ORDER/GROUP BY expression not found in targetlist (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы	Re: ERROR: ORDER/GROUP BY expression not found in targetlist (Tom Lane <tgl@sss.pgh.pa.us>)
Список	pgsql-hackers

Дерево обсуждения

On Mon, Jun 13, 2016 at 10:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Mon, Jun 13, 2016 at 11:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> BTW, decent regression tests could be written without the need to create
> >> enormous tables if the minimum rel size in create_plain_partial_paths()
> >> could be configured to something less than 1000 blocks. I think it's
> >> fairly crazy that that arbitrary constant is hard-wired anyway. Should
> >> we make it a GUC?
>
> > That was proposed before, and I didn't do it mostly because I couldn't
> > think of a name for it that didn't sound unbelievably corny.
>
> min_parallel_relation_size, or min_parallelizable_relation_size, or
> something like that?
>

You are right that such a variable will make it simpler to write tests for parallel query. I have implemented such a guc and choose to keep the name as min_parallel_relation_size. One thing to note is that in function create_plain_partial_paths(), curently it is using PG_INT32_MAX/3 for parallel_threshold to check for overflow, I have changed it to INT_MAX/3 so as to be consistent with guc.c. I am not sure if it is advisable to use PG_INT32_MAX in guc.c as other similar parameters use INT_MAX.

With Regards,

Amit Kapila.

EnterpriseDB: http://www.enterprisedb.com