Revert "Auto-tune effective_cache size to be 4x shared buffers"

This reverts commit ee1e5662d8d8330726eaef7d3110cb7add24d058, as well as
a remarkably large number of followup commits, which were mostly concerned
with the fact that the implementation didn't work terribly well.  It still
doesn't: we probably need some rather basic work in the GUC infrastructure
if we want to fully support GUCs whose default varies depending on the
value of another GUC.  Meanwhile, it also emerged that there wasn't really
consensus in favor of the definition the patch tried to implement (ie,
effective_cache_size should default to 4 times shared_buffers).  So whack
it all back to where it was.  In a followup commit, I'll do what was
recently agreed to, which is to simply change the default to a higher
value.

1 files changed, 2 insertions, 10 deletions

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 9ff230aa6d9..bc5a8870444 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -3194,16 +3194,8 @@ include 'filename'
         memory allocated by <productname>PostgreSQL</productname>, nor
         does it reserve kernel disk cache; it is used only for estimation
         purposes.  The system also does not assume data remains in
-        the disk cache between queries.
-       </para>
-
-       <para>
-        If <varname>effective_cache_size</> is set to -1, which is the
-        default, the value is replaced by an automatically selected value,
-        currently four times the size of <xref linkend="guc-shared-buffers">.
-        For recommended settings of <varname>shared_buffers</>, this should
-        give reasonable results if this database cluster can use most of the
-        memory on the server.
+        the disk cache between queries.  The default is 128 megabytes
+        (<literal>128MB</>).
        </para>
       </listitem>
      </varlistentry>