[doc fix] Really trivial fix for BRIN documentation
Hello,
This is just a correction from "index" to "table". I was a bit confused when I first read this part.
Regards
Takayuki Tsunakawa
Attachments:
brin_trivial_doc_fix.patchapplication/octet-stream; name=brin_trivial_doc_fix.patchDownload
diff -cr a/doc/src/sgml/brin.sgml b/doc/src/sgml/brin.sgml
*** a/doc/src/sgml/brin.sgml 2017-02-21 01:17:14.000000000 +0900
--- b/doc/src/sgml/brin.sgml 2017-02-21 15:18:55.000000000 +0900
***************
*** 63,69 ****
<title>Index Maintenance</title>
<para>
! At the time of creation, all existing index pages are scanned and a
summary index tuple is created for each range, including the
possibly-incomplete range at the end.
As new pages are filled with data, page ranges that are already
--- 63,69 ----
<title>Index Maintenance</title>
<para>
! At the time of creation, all existing table pages are scanned and a
summary index tuple is created for each range, including the
possibly-incomplete range at the end.
As new pages are filled with data, page ranges that are already
On 21 February 2017 at 06:34, Tsunakawa, Takayuki
<tsunakawa.takay@jp.fujitsu.com> wrote:
Hello,
This is just a correction from "index" to "table". I was a bit confused when I first read this part.
Pushed, but using "heap" rather than "table", for clarity. Thanks for the patch.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs [mailto:simon@2ndquadrant.com]
Pushed, but using "heap" rather than "table", for clarity. Thanks for the
patch.
Thank you for responding so quickly. I'm comfortable with "heap." On the other hand, src/backend/access/brin/README uses "table" as follows. Second, I thought users would feel more familiar with the general term "table." Third, I supposed PostgreSQL might add support for other structures for tables than heap in the future, like SQL Server provides heap (non-clustered table) and clustered tables.
At index creation time, the whole table is scanned; for each page range the
summarizing values of each indexed column and nulls bitmap are collected and
stored in the index.
I should have written the reason I chose "table." Anyway, I'm OK with heap.
Regards
Takayuki Tsunakawa
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers