From the look of the select query in the view
SUGGESTION #1 : Don't use VIEWS
Views are notorious for acting up with Query Optimization
According to MySQL Documentation
Indexes can be used for views processed using the merge algorithm. However, a view that is processed with the temptable algorithm is unable to take advantage of indexes on its underlying tables (although indexes can be used during generation of the temporary tables).
Percona calls Views a Performance Troublemaker
SUGGESTION #2 : Use another index (Optional)
You definitely need an additional index to assist the query
ALTER TABLE taxes ADD INDEX propertysid_amount_ndx (propertysid,amount);
ALTER TABLE taxes DROP INDEX propertysid;
That way, all the data needed for the view are in the index only. The other two indexes are not enough. Why do I say that? Even though the propertysid
index was used, the amount has to retrieved from the table. Essentially, the query passes through both the index and the table.
After asking on pgsql-performance list, Jeff Janes figured out that the cause was associated to the default collation used by Postgres (see this link for more informations). MacMini was using the much performing collation while Dell T420 was using the en/US collation.
T420 (Postgres 9.4.1)
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
-----------+----------+----------+-------------+-------------+-----------------------
pen | pen | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres +
| | | | | postgres=CTc/postgres
template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres +
| | | | | postgres=CTc/postgres
(4 rows)
MacMini (Postgres 9.0.13)
List of databases
Name | Owner | Encoding | Collation | Ctype | Access privileges
-------------------+------------+----------+-----------+-------+-------------------------
caldav | caldav | UTF8 | C | C |
collab | collab | UTF8 | C | C |
device_management | _devicemgr | UTF8 | C | C |
pen | pen | UTF8 | C | C |
postgres | _postgres | UTF8 | C | C |
roundcubemail | roundcube | UTF8 | C | C |
template0 | _postgres | UTF8 | C | C | =c/_postgres +
| | | | | _postgres=CTc/_postgres
template1 | _postgres | UTF8 | C | C | =c/_postgres +
| | | | | _postgres=CTc/_postgres
(8 rows)
After setting collation on T420 "C" the A transaction went from 195 seconds to 33 seconds against 40 seconds on Mac Mini; B type transaction went from 141 seconds to 78 seconds against 101 seconds on Mac Mini.
This is the best performance improvement after modifing BIOS settings. Many kernel adjustments didn't provide significant improvements.
So, running the following command will initialize a new database with collation C and encoding UTF8:
/usr/local/pgsql/bin/initdb -D /path/to/your/data --no-locale --encoding=UTF8
I hope this post will help other people in the future. After reading about a lot of digressions about kernel, virtual memory, RAID controllers, disk cache, WAL and other tech stuff I never found someone talking about collations.
Best Answer
This is easy to do inside a PL/pgSQL function (or a DO block):
You can also use GUC variables:
Or you can use a CTE with a join: