From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | zszabo(at)chemaxon(dot)com |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #14495: Cost of comparator is not taken into account in sorting |
Date: | 2017-01-16 14:43:32 |
Message-ID: | 5716.1484577812@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
zszabo(at)chemaxon(dot)com writes:
> Our problem is that the cost of sorting by the Molecule column does not take
> into account the cost of the comparison by molecule_relevance_compare() at
> all!
Yeah, cost_sort just uses cpu_operator_cost as the estimated cost per
comparison. It's unlikely anyone is going to be very excited about
changing that. It would be quite expensive to look up a function-specific
cost on every call, and cost_sort is called often enough during planning
that that expense would be a problem. Also, some call sites don't supply
enough information to do such a lookup at all; requiring them to provide
it would add more expense, and complication. So I don't really see us
adding that much overhead to support such a corner case as an
unduly-expensive sort comparator.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2017-01-17 10:36:45 | Re: Bug in Physical Replication Slots (at least 9.5)? |
Previous Message | nikolay.nikitin | 2017-01-16 13:37:33 | BUG #14499: pg_dump error on the table with 512M or bigger bytea values |