Re: Cost Model - Mailing list pgsql-hackers

From neto brpr
Subject Re: Cost Model
Date
Msg-id CALhhvc2WRuhDskBvZmOsbxsKh6Pw8WUcHphVyNTaXtTHEweyRg@mail.gmail.com
Whole thread Raw
In response to Re: Cost Model  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Cost Model  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Re: Cost Model  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers


2017-12-20 16:35 GMT-02:00 Alvaro Herrera <alvherre@alvh.no-ip.org>:
neto brpr wrote:
> Dear David
> I have read documentation that you send, but it has only sequential page
> cost and random page cost parameters. What I need, would be a model of
> custo for Differentiate Read/Write (sequential and random), because in SSDs
> the reads and writes have different costs.

I don't think it matters.  I mean, differentiating seq/random read
speeds can make the planner choose one plan type over another depending
on how much each plan intends to read randomly or sequentially.  But why
does it matter if one write is 360x as expensive as one read?  No plan
is going to change usefully because of that, because you can't turn one
write into 360 reads or even 100000000 reads.


Just to explain it better. The idea of ​​differentiating read and write parameters (sequential and random) is exactly so that the access plans can be better chosen by the optimizer. But for this, the Hash join, merge join, sorting and other algorithms should also be changed to consider these new parameters. 
Because postgresql uses a cost-based optimizer, I believe that differentiating these costs can have a positive impact on the process of choosing access methods... This is just an opinion, I'm not sure.

If you said "writes of type X are 100 times as fast as writes of type
Y", then some useful cost model could perhaps be developed.  But that's
not what you're saying.


Anyway, It seems that there has not yet been any initiative related to this in the postgresql community, am I right?

Best Regards
Neto
 
--
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Livre de vírus. www.avast.com.

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Proposal: Local indexes for partitioned table
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Proposal: Local indexes for partitioned table