@@ -135,7 +135,7 @@ Administration
135
135
pg_stop_backup() is called or the server is stopped
136
136
137
137
Doing this will allow administrators to know more easily when
138
- the archive contins all the files needed for point-in-time
138
+ the archive contains all the files needed for point-in-time
139
139
recovery.
140
140
141
141
o %Create dump tool for write-ahead logs for use in determining
@@ -185,7 +185,7 @@ Data Types
185
185
* Fix data types where equality comparison isn't intuitive, e.g. box
186
186
* %Prevent INET cast to CIDR if the unmasked bits are not zero, or
187
187
zero the bits
188
- * %Prevent INET cast to CIDR from droping netmask, SELECT '1.1.1.1'::inet::cidr
188
+ * %Prevent INET cast to CIDR from dropping netmask, SELECT '1.1.1.1'::inet::cidr
189
189
* Allow INET + INT4 to increment the host part of the address, or
190
190
throw an error on overflow
191
191
* %Add 'tid != tid ' operator for use in corruption recovery
@@ -457,7 +457,7 @@ SQL Commands
457
457
458
458
This might require some background daemon to maintain clustering
459
459
during periods of low usage. It might also require tables to be only
460
- paritally filled for easier reorganization. Another idea would
460
+ partially filled for easier reorganization. Another idea would
461
461
be to create a merged heap/index data file so an index lookup would
462
462
automatically access the heap data too. A third idea would be to
463
463
store heap rows in hashed groups, perhaps using a user-supplied
@@ -592,7 +592,7 @@ Clients
592
592
593
593
Currently, while \e saves a single statement as one entry, interactive
594
594
statements are saved one line at a time. Ideally all statements
595
- whould be saved like \e does.
595
+ would be saved like \e does.
596
596
597
597
o Allow multi-line column values to align in the proper columns
598
598
@@ -664,10 +664,10 @@ libpq
664
664
665
665
o Allow statement results to be automatically batched to the client
666
666
667
- Currently, all statement results are transfered to the libpq
667
+ Currently, all statement results are transferred to the libpq
668
668
client before libpq makes the results available to the
669
669
application. This feature would allow the application to make
670
- use of the first result rows while the rest are transfered , or
670
+ use of the first result rows while the rest are transferred , or
671
671
held on the server waiting for them to be requested by libpq.
672
672
One complexity is that a statement like SELECT 1/col could error
673
673
out mid-way through the result set.
@@ -743,7 +743,7 @@ Exotic Features
743
743
744
744
* Add the features of packages
745
745
746
- o Make private objects accessable only to objects in the same schema
746
+ o Make private objects accessible only to objects in the same schema
747
747
o Allow current_schema.objname to access current schema objects
748
748
o Add session variables
749
749
o Allow nested schemas
@@ -854,7 +854,7 @@ Cache Usage
854
854
855
855
* Add estimated_count(*) to return an estimate of COUNT(*)
856
856
857
- This would use the planner ANALYZE statistatics to return an estimated
857
+ This would use the planner ANALYZE statistics to return an estimated
858
858
count.
859
859
860
860
* Allow data to be pulled directly from indexes
@@ -880,7 +880,7 @@ Cache Usage
880
880
o Query results
881
881
882
882
* Allow sequential scans to take advantage of other concurrent
883
- sequentiqal scans, also called "Synchronised Scanning"
883
+ sequential scans, also called "Synchronised Scanning"
884
884
885
885
One possible implementation is to start sequential scans from the lowest
886
886
numbered buffer in the shared cache, and when reaching the end wrap
@@ -893,7 +893,7 @@ Vacuum
893
893
894
894
* Improve speed with indexes
895
895
896
- For large table adjustements during VACUUM FULL, it is faster to
896
+ For large table adjustments during VACUUM FULL, it is faster to
897
897
reindex rather than update the index.
898
898
899
899
* Reduce lock time during VACUUM FULL by moving tuples with read lock,
@@ -942,7 +942,7 @@ Startup Time Improvements
942
942
943
943
This would prevent the overhead associated with process creation. Most
944
944
operating systems have trivial process creation time compared to
945
- database startup overhead, but a few operating systems (WIn32 ,
945
+ database startup overhead, but a few operating systems (Win32 ,
946
946
Solaris) might benefit from threading. Also explore the idea of
947
947
a single session using multiple threads to execute a statement faster.
948
948
0 commit comments