Re: Doubts about pushing LIMIT to MergeAppendPath
От | Tomas Vondra |
---|---|
Тема | Re: Doubts about pushing LIMIT to MergeAppendPath |
Дата | |
Msg-id | 4af4442d-ccf1-43cf-7aeb-ee23d8723829@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Doubts about pushing LIMIT to MergeAppendPath (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Ответы |
Re: Doubts about pushing LIMIT to MergeAppendPath
|
Список | pgsql-hackers |
On 11/01/2018 08:11 PM, Tomas Vondra wrote: > On 11/01/2018 12:48 PM, Antonin Houska wrote: >> Review of [1] made me think of this optimization, currently used only in >> create_merge_append_path(): >> >> /* >> * Apply query-wide LIMIT if known and path is for sole base relation. >> * (Handling this at this low level is a bit klugy.) >> */ >> if (bms_equal(rel->relids, root->all_baserels)) >> pathnode->limit_tuples = root->limit_tuples; >> else >> pathnode->limit_tuples = -1.0; >> >> Currently it's not a problem because the output of MergeAppend plan is not >> likely to be re-sorted, but I don't think data correctness should depend on >> cost evaluation. Instead, -1 should be set here if there's any chance that the >> output will be sorted again. >> > > So you're saying we might end up with a plan like this: > > Limit > -> Sort > -> MergeAppend > -> SeqScan on t > > In which case we'd pass the wrong limit_tuples to the MergeAppend? > > Hmmm, that would depend on us building MergeAppend node that does not > match the expected pathkeys, and pick it instead of plain Append node. > I'm not sure that's actually possible, but maybe it is ... > OK, so the reason is that when building child paths, we don't keep the pathkeys unless it matches the "interesting" pathkeys. So for example we may have an IndexPath, but with pathkeys=NIL if the index does not match the ORDER BY we need. So we don't even build the MergeAppend paths, as generate_mergeappend_paths iterates over child pathkeys (and we don't have any). We might have two child paths, one with pathkeys (matching the ORDER BY) and one without pathkeys. But at that point the optimization does not apply, because it checks for "single base relation". At least that's my understanding of add_paths_to_append_rel(). regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: