Re: Unwanted expression simplification in PG12b2

Поиск
Список
Период
Сортировка
От Finnerty, Jim
Тема Re: Unwanted expression simplification in PG12b2
Дата
Msg-id FBD5010F-DF47-4C24-B7B8-ABF6031A69D1@amazon.com
обсуждение исходный текст
Ответ на Re: Unwanted expression simplification in PG12b2  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Unwanted expression simplification in PG12b2  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
If the function was moved to the FROM clause where it would be executed as a lateral cross join instead of a target
listexpression, how would this affect the cost-based positioning of the Gather?
 

On 9/23/19, 8:59 AM, "Robert Haas" <robertmhaas@gmail.com> wrote:

    On Sun, Sep 22, 2019 at 7:47 AM Darafei "Komяpa" Praliaskouski
    <me@komzpa.net> wrote:
    > A heuristic I believe should help my case (and I hardly imagine how it can break others) is that in presence of
Gather,all the function calls that are parallel safe should be pushed into it.
 
    
    The cost of pushing data through the Sort is not necessarily
    insignificant.  Your functions are (IIUC) extremely expensive, so it's
    worth going to any length to reduce the time spent evaluating them.
    However, if someone has ||(text,text) in the tlist, that might be the
    wrong approach, because it's not saving much to compute that earlier
    and it might make the sort a lot wider, especially if de-TOASTing is
    involved.
    
    -- 
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise PostgreSQL Company
    
    
    


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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: PATCH: standby crashed when replay block which truncated instandby but failed to truncate in master node