On 2018-11-29 17:53:31 +0100, Dmitry Dolgov wrote:
> > On Tue, Oct 2, 2018 at 3:58 AM Michael Paquier wrote:
> >
> > On Sun, Jul 22, 2018 at 10:22:10PM +0200, Tomas Vondra wrote:
> > > Could you perhaps summarize the reasoning or at least point me to the
> > > relevant parts of the sources, so tha
> On Tue, Oct 2, 2018 at 3:58 AM Michael Paquier wrote:
>
> On Sun, Jul 22, 2018 at 10:22:10PM +0200, Tomas Vondra wrote:
> > Could you perhaps summarize the reasoning or at least point me to the
> > relevant parts of the sources, so that I know which parts to focus on?
>
> Teodor, this patch is w
On Sun, Jul 22, 2018 at 10:22:10PM +0200, Tomas Vondra wrote:
> Could you perhaps summarize the reasoning or at least point me to the
> relevant parts of the sources, so that I know which parts to focus on?
Teodor, this patch is waiting for some input from you. I have moved it
to next CF for now,
On 07/12/2018 04:31 PM, Teodor Sigaev wrote:
>> At least [1] and [2] hit into to that issues and have an
>> objections/questions about correctness of cost sort estimation.
>> Suggested patch tries to improve current estimation and solve that
>> issues.
>
> Sorry for long delay but issue was even m
On 07/12/2018 05:00 PM, Teodor Sigaev wrote:
>
>> One more thought about estimating the worst case - I wonder if simply
>> multiplying the per-tuple cost by 1.5 is the right approach. It does not
>> seem particularly principled, and it's trivial simple to construct
>> counter-examples defeating
One more thought about estimating the worst case - I wonder if simply
multiplying the per-tuple cost by 1.5 is the right approach. It does not
seem particularly principled, and it's trivial simple to construct
counter-examples defeating it (imagine columns with 99% of the rows
having the same v
V8 contains fixes of Tomas Vondra complaints:
- correct usage of comparison_cost
- remove uneeded check of sortop
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
diff --git a/src/backend/o
OK, so Fi is pretty much whatever CREATE FUNCTION ... COST says, right?
exactly
Hmm, makes sense. But doesn't that mean it's mostly a fixed per-tuple
cost, not directly related to the comparison? For example, why should it
be multiplied by C0? That is, if I create a very expensive comparator
(s
At least [1] and [2] hit into to that issues and have an objections/questions
about correctness of cost sort estimation. Suggested patch tries to improve
current estimation and solve that issues.
Sorry for long delay but issue was even more complicated than I thought. When I
tried to add cost_
On 06/28/2018 06:47 PM, Teodor Sigaev wrote:
> Hi!
>
> ...
>
> - cost for i-th columns:
> Ci * log2(NGi) => Ci * log2(N/G(i-1))
> So, here I believe, that i-th comparison function will be called only
> inside
> group which number is defined by (i-1) leading columns. Note, following
> d
Hi,
I'll do more experiments/tests next week, but let me share at least some
initial thoughts ...
On 06/28/2018 06:47 PM, Teodor Sigaev wrote:
> Hi!
>
> Current estimation of sort cost has following issues:
> - it doesn't differ one and many columns sort
> - it doesn't pay attention to compari
On 06/29/2018 04:36 PM, Teodor Sigaev wrote:
>
>
> Peter Geoghegan wrote:
>> On Thu, Jun 28, 2018 at 9:47 AM, Teodor Sigaev wrote:
>>> Current estimation of sort cost has following issues:
>>> - it doesn't differ one and many columns sort
>>> - it doesn't pay attention to comparison funct
Peter Geoghegan wrote:
On Thu, Jun 28, 2018 at 9:47 AM, Teodor Sigaev wrote:
Current estimation of sort cost has following issues:
- it doesn't differ one and many columns sort
- it doesn't pay attention to comparison function cost and column width
- it doesn't try to count number of c
On Thu, Jun 28, 2018 at 9:47 AM, Teodor Sigaev wrote:
> Current estimation of sort cost has following issues:
> - it doesn't differ one and many columns sort
> - it doesn't pay attention to comparison function cost and column width
> - it doesn't try to count number of calls of comparison funct
Hi!
Current estimation of sort cost has following issues:
- it doesn't differ one and many columns sort
- it doesn't pay attention to comparison function cost and column width
- it doesn't try to count number of calls of comparison function on per column
basis
At least [1] and [2] hit into
15 matches
Mail list logo