Re: ERROR: ORDER/GROUP BY expression not found in targetlist
От | Tom Lane |
---|---|
Тема | Re: ERROR: ORDER/GROUP BY expression not found in targetlist |
Дата | |
Msg-id | 25521.1465837597@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: ERROR: ORDER/GROUP BY expression not found in targetlist (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: ERROR: ORDER/GROUP BY expression not found in targetlist
Re: ERROR: ORDER/GROUP BY expression not found in targetlist |
Список | pgsql-hackers |
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? > Also, > the whole way that algorithm works is kind of a hack and probably > needs to be overhauled entirely in some future release. I'm worried > about having the words "backward compatibility" thrown in my face when > it's time to improve this logic. But aside from those two issues I'm > OK with exposing a knob. I agree it's a hack, and I don't want to expose anything about the number-of-workers scaling behavior, for precisely that reason. But a threshold on the size of a table to consider parallel scans for at all doesn't seem unreasonable. regards, tom lane
В списке pgsql-hackers по дате отправления: