Olá, bom dia Se alguém puder me indicar o que significa essa mensagem que foi emitida ao aplicar um Patch nos fontes da versão 9.0.1. Eu verifiquei os arquivos que o Patch altera do código fonte e a principio foram alterados corretamente.
Mensagem:" (Stripping trailing CRs from patch; use --binary to disable.) " ------------------ Aplicação do comando e mensagem de alerta ---------------- projeto@neto-pc:~/Downloads/postgresql-9.0.1$ patch -p1 < /home/projeto/Downloads/patchssdpg/0001-Split-up-page-cost-options-into-read-and-write.patch (Stripping trailing CRs from patch; use --binary to disable.) patching file doc/src/sgml/config.sgml (Stripping trailing CRs from patch; use --binary to disable.) patching file doc/src/sgml/indexam.sgml (Stripping trailing CRs from patch; use --binary to disable.) . . . ----------------------------------------------------------------------------------------------------- Segue um Trecho do Patch 0001-Split-up-page-cost-options-into-read-and-write.patch ------------------- ARQUIVO Patch 0001-Split-up-page-cost-options-into-read-and-write.patch --------------------------- From bcbff6ee8f3ca9a1d7128f00831bd0587a38566f Mon Sep 17 00:00:00 2001 From: Daniel Bausch <[email protected]> Date: Tue, 18 Jan 2011 01:43:50 +0100 Subject: [PATCH 1/9] Split up page cost options into read and write This allows better adaption to devices with asymmetric response times when it comes to reading and writing. SSDs and PCMs are such devices. New page cost parameters replace the old ones preserving their semantic. If in the previous version an occourence of seq_page_cost modeled a read operation then it is replaced by this commit with seq_read_page_cost, otherwise, if that reference to seq_page_cost modeled a write operation it is replaced with seq_write_page_cost. The same logic is used to replace random_page_cost with random_read_page_cost or random_write_page_cost respectively. This is a shorter version of the longer change 9b13c68 against the master branch. It does not change the function gincostestimate in selfuncs.c because in 9.0.1 that function contains a call to genericcostestimate only while in master it is hand coded and contains references to the page cost variables. --- doc/src/sgml/config.sgml | 75 +++++++++++++--- doc/src/sgml/indexam.sgml | 18 ++-- doc/src/sgml/perform.sgml | 19 ++-- doc/src/sgml/ref/alter_tablespace.sgml | 12 +-- doc/src/sgml/release-8.2.sgml | 4 +- src/backend/access/common/reloptions.c | 8 +- src/backend/optimizer/path/costsize.c | 123 +++++++++++++++----------- src/backend/utils/adt/selfuncs.c | 16 ++-- src/backend/utils/cache/spccache.c | 20 ++--- src/backend/utils/misc/guc.c | 30 +++++-- src/backend/utils/misc/postgresql.conf.sample | 6 +- src/bin/psql/tab-complete.c | 2 +- src/include/commands/tablespace.h | 4 +- src/include/optimizer/cost.h | 12 ++- src/include/utils/spccache.h | 4 +- src/test/regress/input/tablespace.source | 6 +- src/test/regress/output/tablespace.source | 6 +- 17 files changed, 230 insertions(+), 135 deletions(-) diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 39be624..4fdd48b 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -2264,7 +2264,7 @@ SET ENABLE_SEQSCAN TO OFF; scaling them all up or down by the same factor will result in no change in the planner's choices. By default, these cost variables are based on the cost of sequential page fetches; that is, - <varname>seq_page_cost</> is conventionally set to <literal>1.0</> + <varname>seq_read_page_cost</> is conventionally set to <literal>1.0</> and the other cost variables are set with reference to that. But you can use a different scale if you prefer, such as actual execution times in milliseconds on a particular machine. @@ -2282,10 +2282,10 @@ SET ENABLE_SEQSCAN TO OFF; <variablelist> - <varlistentry id="guc-seq-page-cost" xreflabel="seq_page_cost"> - <term><varname>seq_page_cost</varname> (<type>floating point</type>)</term> + <varlistentry id="guc-seq-read-page-cost" xreflabel="seq_read_page_cost"> + <term><varname>seq_read_page_cost</varname> (<type>floating point</type>)</term> <indexterm> - <primary><varname>seq_page_cost</> configuration parameter</primary> + <primary><varname>seq_read_page_cost</> configuration parameter</primary> </indexterm> <listitem> <para> @@ -2298,10 +2298,10 @@ SET ENABLE_SEQSCAN TO OFF; </listitem> </varlistentry> - <varlistentry id="guc-random-page-cost" xreflabel="random_page_cost"> - <term><varname>random_page_cost</varname> (<type>floating point</type>)</term> + <varlistentry id="guc-random-read-page-cost" xreflabel="random_read_page_cost"> + <term><varname>random_read_page_cost</varname> (<type>floating point</type>)</term> <indexterm> - <primary><varname>random_page_cost</> configuration parameter</primary> + <primary><varname>random_read_page_cost</> configuration parameter</primary> </indexterm> <listitem> <para> @@ -2313,7 +2313,7 @@ SET ENABLE_SEQSCAN TO OFF; </para> <para> - Reducing this value relative to <varname>seq_page_cost</> + Reducing this value relative to <varname>seq_read_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 @@ -2323,8 +2323,8 @@ SET ENABLE_SEQSCAN TO OFF; <tip> <para> - Although the system will let you set <varname>random_page_cost</> to - less than <varname>seq_page_cost</>, it is not physically sensible + Although the system will let you set <varname>random_read_page_cost</> to + less than <varname>seq_read-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 @@ -2336,6 +2336,61 @@ SET ENABLE_SEQSCAN TO OFF; </listitem> </varlistentry> + <varlistentry id="guc-seq-write-page-cost" xreflabel="seq_write_page_cost"> + <term><varname>seq_write_page_cost</varname> (<type>floating point</type>)</term> + <indexterm> + <primary><varname>seq_write_page_cost</> configuration parameter</primary> + </indexterm> + <listitem> + <para> + Sets the planner's estimate of the cost of a disk page write + that is part of a series of sequential writes. The default is 1.0, + what assumes a symmetric performing storage device like a hard disk + drive. + </para> + <tip> + <para>When the database resides on a asymmetric memory device like a + flash SSD or an even more modern phase change memory device, you + should increase this value, to prefer plans, that do not write + intermediate results. + </para> + </tip> + <para> + This value can be overridden for a particular tablespace by setting + the tablespace parameter of the same name + (see <xref linkend="sql-altertablespace">). + </para> + </listitem> + </varlistentry> + + <varlistentry id="guc-random-write-page-cost" xreflabel="random_write_page_cost"> + <term><varname>random_write_page_cost</varname> (<type>floating point</type>)</term> + <indexterm> + <primary><varname>random_write_page_cost</> configuration parameter</primary> + </indexterm> + <listitem> + <para> + Sets the planner's estimate of the cost of a non-sequentially-written + disk page. The default is 4.0, what assumes a symmetric performing + storage device like a hard disk drive. + </para> + <tip> + <para>When the database resides on a asymmetric memory device like a + flash SSD or an even more modern phase change memory device, you + should increase this value, to prefer plans, that do not write + intermediate results. Random writes on such a device are usually + slower than sequential writes, so plans using such operations + intensively should be avoided. + </para> + </tip> + <para> + This value can be overridden for a particular tablespace by setting + the tablespace parameter of the same name + (see <xref linkend="sql-altertablespace">). + </para> + </listitem> + </varlistentry> + <varlistentry id="guc-cpu-tuple-cost" xreflabel="cpu_tuple_cost"> <term><varname>cpu_tuple_cost</varname> (<type>floating point</type>)</term> <indexterm> diff --git a/doc/src/sgml/indexam.sgml b/doc/src/sgml/indexam.sgml index a17a4fd..3bb86ba 100644 --- a/doc/src/sgml/indexam.sgml +++ b/doc/src/sgml/indexam.sgml @@ -946,9 +946,11 @@ amcostestimate (PlannerInfo *root, <para> The index access costs should be computed using the parameters used by <filename>src/backend/optimizer/path/costsize.c</filename>: a sequential - disk block fetch has cost <varname>seq_page_cost</>, a nonsequential fetch - has cost <varname>random_page_cost</>, and the cost of processing one index - row should usually be taken as <varname>cpu_index_tuple_cost</>. In + disk block fetch has cost <varname>seq_read_page_cost</>, a nonsequential + fetch has cost <varname>random_read_page_cost</> while disk writes are + represented by <varname>seq_write_page_cost</> + and <varname>random_write_page_cost</>. The cost of processing one index + row should usually be taken as <varname>cpu_index_tuple_cost</>, and in addition, an appropriate multiple of <varname>cpu_operator_cost</> should be charged for any comparison operators invoked during index processing (especially evaluation of the <literal>indexQuals</> themselves). @@ -1028,14 +1030,14 @@ amcostestimate (PlannerInfo *root, <programlisting> /* - * Our generic assumption is that the index pages will be read - * sequentially, so they cost seq_page_cost each, not random_page_cost. - * Also, we charge for evaluation of the indexquals at each index row. - * All the costs are assumed to be paid incrementally during the scan. + * Our generic assumption is that the index pages will be read sequentially, + * so they cost seq_read_page_cost each, not random_read_page_cost. Also, + * we charge for evaluation of the indexquals at each index row. All the + * costs are assumed to be paid incrementally during the scan. */ cost_qual_eval(&index_qual_cost, indexQuals, root); *indexStartupCost = index_qual_cost.startup; -*indexTotalCost = seq_page_cost * numIndexPages + +*indexTotalCost = seq_read_page_cost * numIndexPages + (cpu_index_tuple_cost + index_qual_cost.per_tuple) * numIndexTuples; </programlisting> diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml index 4307370..df76c5d 100644 --- a/doc/src/sgml/perform.sgml +++ b/doc/src/sgml/perform.sgml @@ -115,13 +115,12 @@ EXPLAIN SELECT * FROM tenk1; </para> ... o arquivo continua, mas aqui foi cortado... =========================================== _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
