bit on the indexes.
I also attach clusterdb and clusterdb.sgml; both of them are blatant
rips of vacuumdb and vacuumdb.sgml, but get the job done. Please review
them, as I'm probably making a lot of mistakes with SGML and I can't
compile it here.
vacuumdb itself is not very comfortable to use when the databases have
passwords, because it has to connect once for each table (I can probably
make it connect only once for each database; should I?). Because of
this I added a mention of PGPASSWORDFILE in the documentation, but I
don't know if that is the correct place for that.
Alvaro Herrera
that ANALYZE would not gather any stats for a CHAR(255) column. I still
think a width threshold is appropriate for the reasons mentioned in the
code, but we can loosen it at least.
array header, and to compute sizing and alignment of array elements
the same way normal tuple access operations do --- viz, using the
tupmacs.h macros att_addlength and att_align. This makes the world
safe for arrays of cstrings or intervals, and should make it much
easier to write array-type-polymorphic functions; as examples see
the cleanups of array_out and contrib/array_iterator. By Joe Conway
and Tom Lane.
width types and varlena types, since with the introduction of CSTRING as
a more-or-less-real type, these concepts aren't identical. I've tried to
use varlena consistently to denote datatypes with typlen = -1, ie, they
have a length word and are potentially TOASTable; while the term variable
width covers both varlena and cstring (and, perhaps, someday other types
with other rules for computing the actual width). No code changes in this
commit except for renaming a couple macros.
value '-2' is used to indicate a variable-width type whose width is
computed as strlen(datum)+1. Everything that looks at typlen is updated
except for array support, which Joe Conway is working on; at the moment
it wouldn't work to try to create an array of cstring.
the server. Previously we allocated a new String object for the entire final
query we were sending to the database. If you had a big query, or especially
if you had large bind values you ended up with essentially two copies in memory.
This change will reuse the existing objects and therefore should take 1/2 the
memory it does today for a given query. This restructuring will also allow
in the future the ability to stream bytea data to the server instead of the current approach of pulling it all into memory.
I also fixed a test that was failing on a 7.2 database.
Also renamed some internal variables and some minor cleanup.
Modified Files:
jdbc/org/postgresql/core/QueryExecutor.java
jdbc/org/postgresql/jdbc1/AbstractJdbc1Connection.java
jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
jdbc/org/postgresql/jdbc2/AbstractJdbc2ResultSet.java
jdbc/org/postgresql/jdbc2/AbstractJdbc2Statement.java
jdbc/org/postgresql/test/jdbc2/DatabaseMetaDataTest.java
