Re: Long Running Update

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Harry Mantheakis <harry.mantheakis@xxxxxxxxxxxxxxxxxxxxxx> 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

-- 
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance


[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux