Re: Long Running Update - Mailing list pgsql-performance

From Kevin Grittner
Subject Re: Long Running Update
Date
Msg-id 4E045227020000250003EBA2@gw.wicourts.gov
Whole thread Raw
In response to Re: Long Running Update  (Harry Mantheakis <harry.mantheakis@riskcontrollimited.com>)
List pgsql-performance
Harry Mantheakis <harry.mantheakis@riskcontrollimited.com> wrote:

> IOW how do I convert - guesstimate! - these numbers into
> (plausible) time values?

They are abstract and it only matters that they are in the right
ratios to one another so that the planner can accurately pick the
cheapest plan.  With the default settings, seq_page_cost is 1, so if
everything is tuned perfectly, the run time should match the time it
takes to sequentially read a number of pages (normally 8KB) which
matches the estimated cost.  So with 8KB pages and seq_page_cost =
1, the cost number says it should take the same amount of time as a
sequential read of 130 GB.

The biggest reason this won't be close to actual run time is that is
that the planner just estimates the cost of *getting to* the correct
tuples for update, implicitly assuming that the actual cost of the
updates will be the same regardless of how you find the tuples to be
updated.  So if your costs were set in perfect proportion to
reality, with seq_page_cost = 1, the above would tell you how fast a
SELECT of the data to be updated should be.  The cost numbers don't
really give a clue about the time to actually UPDATE the rows.

-Kevin

pgsql-performance by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Long Running Update
Next
From: Devrim GÜNDÜZ
Date:
Subject: Cost of creating an emply WAL segment