There are also commercial and hardware-based replication solutions available supporting a variety of replication models.
+ +All text types in PostgreSQL are case-sensitive. This is generally + what you want. If you have an identifier in a table that must be a + particular format, it's better to use a CHECK constraint. + If you want to avoid duplicates that differ only in case, create a + UNIQUE index like so: + +
+ CREATE UNIQUE INDEX mytable_myfield ON mytable ( lower(myfield) ); ++ +
If you want to do case-insensitive searches then that index can help + you also (in a non-unique form). For regular expressions, see FAQ 4.8. + +
If you really need to have a column that is case-insensitive (perhaps + for porting) there is a project on GBorg called citext + which can give you a case insensitive text data type. + +
Actually, what happens is that unquoted identifiers are folded to a + single case before comparison. The SQL standard requires folding to + uppercase, PostgreSQL folds to lowercase. What this means is that the + identifiers MyTable, Mytable and + "mytable" all compare the same. But + "MyTable", "Mytable" and + "MYTABLE" are all different, even in totally SQL + compliant databases. + +
The usual cause for this complaint is that people use a GUI admin + interface to create their tables and it has helpfully quoted the table + and field names so that only identical quoting everywhere else can match + it. + +
A good rule of thumb is to either always quote your identifiers + (in which case you must get the case right all the time) or never + quote them (in which case the case never matters). + +
If this is your problem, then you can use your admin interface to rename + all the columns to all-lowercase names. Or execute queries like those + below. + +
+ ALTER TABLE "MyTable" RENAME TO MyTable; + ALTER TABLE MyTable RENAME "MyField" TO MyField; ++ +
The PostgreSQL process model has one single threaded backend handling + each client. This means that multiple queries from different clients + will have their loads spread out as determined most appropriate by the + operating system. But within a single query there is only a single + thread of execution, so a single query is run only on one CPU (though + the OS can move it around, PostgreSQL is unaware of this). + +
Usually this is not a problem as the system is generally I/O bound + (limited by disk speed), not CPU bound. However, for some unusual + workloads you may need to think about connecting more than once to the + same database so you can have different portions work in parallel. + +
PostgreSQL itself has no facility fire jobs off at regular intervals, + it is recommended to use the operating system to handle this. For UNIX + systems this generally means cron, for Windows systems it + may mean the Task Scheduler. + +
A seperate project has started with the goal to create a job + scheduler for PostgreSQL, see pgjobs. + +
Unlike some databases, PostgreSQL allows you to create an index on + any column, including unlimited text fields. However, B-Tree indexes + need to be able to hold at least three key values per page and since the + pagesize defaults to 8K minus some overhead, this means the maximum key + size is 2713 bytes. + +
Usually it serves no purpose to have an index on such a column. If + you're doing it for searches, remember that a normal index doesn't help + searching within a string (eg LIKE '%abc%'). What you are + probably looking for is Full Text Indexing, see TSearch2 + and OpenFTS. If you're not + actually doing searching in that column then perhaps you don't need that + index at all. + +
If all you want to do is make sure the values are unique, the + recommended technique is to use a trigger to calculate an MD5 of the + value and put a unique index on this. Obviously this won't help searching. + +
If you're really desparate, you can increase the pagesize a bit (to + 32K) but this requires recompiling and reinstalling your database from + scratch. From then on it will be incompatable with other people's + databases, so think carefully whether your successor will remember to do + this next time they upgrade. + +
Also note, that no index type can ever exceed the pagesize limit, + although hash indexes can go up to just under one page. Full text + indexing works because it doesn't store the whole key directly. +