postgresqlco.nf Open in urlscan Pro
65.9.95.23  Public Scan

Form analysis
1 forms found in the DOM

GET #

<form action="#" method="get" class="sidebar-form">
  <div class="input-group">
    <input type="text" name="q" id="search" class="search form-control" data-toggle="hideseek" placeholder="Search parameter" data-list=".sidebar-menu">
    <span class="input-group-btn">
      <div id="search-btn" class="btn btn-flat">
        <i style="color:#ffffff" class="fa fa-search"></i>
      </div>
    </span>
  </div>
</form>

Text Content

POSTGRESQLCO.NF
Manage
CO.NF for your Blog
Configuration Snippet Parameter Snippet

POSTGRESQL CONFIGURATION FOR HUMANS

PostgreSQL version:
 * 9.1 eol
 * 9.2 eol
 * 9.3 eol
 * 9.4 eol
 * 9.5 eol
 * 9.6 eol
 * 10 eol
 * 11 stable
 * 12 stable
 * 13 stable
 * 14 stable
 * 15 stable
 * 16 current

   Close
   
 * CATEGORIES
   
   --------------------------------------------------------------------------------

 *   PARAMETERS
   
   


RANDOM_PAGE_COST

 1. Documentation
 2. Query Tuning
 3. Planner Cost Constants
 4. random_page_cost

COPY SHARING LINK

Type: real Default: 4 Min: 0 Max: 1.79769e+308 Context: user Restart: false

Sets the planner's estimate of the cost of a nonsequentially fetched disk page

Sets the planner's estimate of the cost of a non-sequentially-fetched disk page.
The default is 4.0. This value can be overridden for tables and indexes in a
particular tablespace by setting the tablespace parameter of the same name (see
sql-altertablespace).

Reducing this value relative to seq_page_cost will cause the system to prefer
index scans; raising it will make index scans look relatively more expensive.
You can raise or lower both values together to change the importance of disk I/O
costs relative to CPU costs, which are described by the following parameters.

Random access to mechanical disk storage is normally much more expensive than
four times sequential access. However, a lower default is used (4.0) because the
majority of random accesses to disk, such as indexed reads, are assumed to be in
cache. The default value can be thought of as modeling random access as 40 times
slower than sequential, while expecting 90% of random reads to be cached.

If you believe a 90% cache rate is an incorrect assumption for your workload,
you can increase random_page_cost to better reflect the true cost of random
storage reads. Correspondingly, if your data is likely to be completely in
cache, such as when the database is smaller than the total server memory,
decreasing random_page_cost can be appropriate. Storage that has a low random
read cost relative to sequential, e.g., solid-state drives, might also be better
modeled with a lower value for random_page_cost, e.g., 1.1.

Although the system will let you set random_page_cost to less than
seq_page_cost, it is not physically sensible to do so. However, setting them
equal makes sense if the database is entirely cached in RAM, since in that case
there is no penalty for touching pages out of sequence. Also, in a
heavily-cached database you should lower both values relative to the CPU
parameters, since the cost of fetching a page already in RAM is much smaller
than it would normally be.

Official docs


Search in source code

RECOMMENDATIONS

Sets the ratio of seek to scan time for your database storage. Should not be
altered unless you're using special storage (SSDs, high end SANs, etc.) where
seek/scan ratios are actually different. If you need the database to favor
indexes more, tune effective_cache_size and some of the cpu_* costs instead.
By annotated.conf

ON STACKOVERFLOW

 * What exactly means the collation 'de-DE-u-kn-true'
 * Probleme d'installation de pgadmin
 * De-Identifying PHI For HIPAA
 * Lazily (de-)serialize JSON with EF Core
 * Connect to a heroku database with pgadmin

ON PGSQL-HACKERS

 * Re: POC, WIP: OR-clause support for indexes
 * Re: Use of additional index columns in rows filtering
 * Re: BitmapHeapScan streaming read user and prelim refactoring
 * Re: Forgive trailing semicolons inside of config files
 * Forgive trailing semicolons inside of config files

COMMENTS


Please enable JavaScript to view the comments powered by Disqus.
© 2024 OnGres, Inc.   
Feedback    Privacy policy