DOC: implemented feedback for in-memory

Author: Liudmila Mantrova

doc/src/sgml/in-memory.sgml

@@ -16,23 +16,22 @@
         <para>
          Fast random access on the primary key.
          This can result in significant performance benefits when
-         working with data that has to be moved to RAM and requires
-         a very high read and write access rate,
-         especially on multi-core systems.
+         working with data that requires a very high read and write
+         access rate, especially on multi-core systems.
         </para>
       </listitem>
       <listitem>
         <para>
-         Saving disk space: there is no primary key
-         duplication as all data is stored directly in the index.
+         Effective space usage.
+         There is no primary key duplication as all data
+         is stored directly in the index.
         </para>
       </listitem>
     </itemizedlist>
   </para>
 
   <para>
-    Just like regular heap-organized tables,
-    in-memory tables support transactions, including savepoints.
+    In-memory tables support transactions, including savepoints.
     However, the data in such tables is stored only while the server is running.
     Once the server is shut down, all in-memory data gets truncated.
     When using in-memory tables, you should also take into account the following
@@ -202,20 +201,20 @@ OPTIONS (INDICES '(id, author COLLATE "ru_RU" ASC)');
      Fill the <structname>blog_views</structname>
      table with initial zero values for initial ten blog posts:
     <programlisting>
-# INSERT INTO blog_views (SELECT id, 0 FROM generate_series(1, 10) AS id);
+postgres=# INSERT INTO blog_views (SELECT id, 0 FROM generate_series(1, 10) AS id);
 </programlisting>
 </para>
 
 <para>Increment the view count for a couple of posts
 and display the result:
 <programlisting>
-# UPDATE blog_views SET views = views + 1 WHERE id = 1;
+postgres=# UPDATE blog_views SET views = views + 1 WHERE id = 1;
 UPDATE 1
-# UPDATE blog_views SET views = views + 1 WHERE id = 1;
+postgres=# UPDATE blog_views SET views = views + 1 WHERE id = 1;
 UPDATE 2
-# UPDATE blog_views SET views = views + 1 WHERE id = 2;
+postgres=# UPDATE blog_views SET views = views + 1 WHERE id = 2;
 UPDATE 1
-# SELECT * FROM blog_views WHERE id = 1 OR id = 2;
+postgres=# SELECT * FROM blog_views WHERE id = 1 OR id = 2;
  id | views
 ----+-------
   1 |  2
@@ -227,7 +226,7 @@ UPDATE 1
       Check planning and execution costs for a query that
       only requires a primary key lookup:
     <programlisting>
-# EXPLAIN ANALYZE SELECT * FROM blog_views WHERE id = 1;
+postgres=# EXPLAIN ANALYZE SELECT * FROM blog_views WHERE id = 1;
                        QUERY PLAN
 -------------------------------------------------------------------
 Foreign Scan on blog_views  (cost=0.02..0.03 rows=1 width=16)
@@ -242,7 +241,7 @@ Execution time: 0.035 ms
       Check the costs of calculating the sum of all views, which requires
       a full index scan:
     <programlisting>
-# EXPLAIN ANALYZE SELECT SUM(views) FROM blog_views;
+postgres=# EXPLAIN ANALYZE SELECT SUM(views) FROM blog_views;
                          QUERY PLAN
 --------------------------------------------------------------------
 Aggregate  (cost=1.62..1.63 rows=1 width=32)
@@ -319,7 +318,7 @@ Execution time: 0.353 ms
       as well as the total number of pages allocated for in-memory tables.
       For example:
     <screen>
-# SELECT * FROM in_memory.in_memory_page_stats();
+postgres=# SELECT * FROM in_memory.in_memory_page_stats();
  used_pages | free_pages | all_pages
 ------------+------------+-----------
         576 |       7616 |      8192