Postgresql – Installing PostgreSQL 9.2 and PostGIS 2.0 on Ubuntu 12

I was having this issue on Windows 7 64-bit and the following solution is what worked for me (via http://igordcard.blogspot.com/2012/03/unable-to-write-inside-temp-environment.html):

Why
To understand why this error was happening, I went to my TEMP folder and read the log from the PostgreSQL installer: C:\Users\myuser\AppData\Local\Temp\bitrock_installer.log

Which mentioned an interesting detail:
Input Error: There is no script engine for file extension ".vbs".

So, I picked up another file from the TEMP folder, the actual script used by the installer:
C:\Users\myuser\AppData\Local\Temp\prerun_checks.vbs

And tried to run it through the console using cscript:
Input Error: There is no script engine for file extension ".vbs".

I researched a bit more and discovered that the type of file associated with the vbs extension had been changed. In my case, by Notepad++. After I installed Notepad++, I associated some file extensions with it (including vbs), thus causing problems when detecting the type of the script (which shouldn't happen).

Solution
Run regedit, navigate to HKEY_CLASSES_ROOT\.vbs and change the (Default) key back to the string VBSFile. In my case it had been previously altered to Notepad++_file.

As a part of my work I maintain a fairly large PostgreSQL database (around 120gb on disk, several multi-million-row tables) and have collected a few tricks on how to speed up the queries. First some comments on your assumptions:

1. Yes, order is important, but it's only the first one that is really different, the rest are second class indexes.
2. I'm not sure it will always use both, my guess is that the query planner will use #1, then do something clever with the rest.
3. I have no experience with GIST.
4. Yes, add all indexes first, see what is used the most and what gives the best performance.
5. I would sugest that you try both and measure what works best. Try rewriting the sql with different subqueries, maybe country and time in one, then join with the intersect-query. I have not noticed any performance problem with IN-clauses, as long as the IN-list is not thousands of elements long. My guess is that a few different queries specifically tuned depending on the input criteria available will give the best results.

6. I would suggest against making a 4-way index. Try creating one and then check the size, they can get really huge. In my experience, four 1-key indexes have been almost as fast as a single 4-way index. A trick that does work nicely for some specific queries are partial indexes, ie something like this:

   CREATE INDEX ON table_x (key1, key2, key3) WHERE some_x_column = 'XXXX';

I have created aliases in my .psqlrc-file with queries to help find what indexes to add or remove. Feel free to have a look at them over at GitHub: .psql

I use the :seq_scans and :bigtables a lot, and then \d table_name to get details about the table. Don't forget to reset the statistics after you've done some changes, select pg_stat_reset();