Postgres performance testing, caching and flushing
PostgreSQL relies heavily on the OS cache as well as its own cache.  So you would have to clear the PostgreSQL cache (restart the postgres service) and clear the OS cache (either restart the machine, or follow the method in the comments to clear without restarting if you are Linux).

But, why do you want to do it this way?  If the query is parameterized, you could just change the parameters each time so they refer to a different part of the data.  If the query is not parameterized, then why is the data it needs getting driven out of the cache between runs on the production machine?

When the different parameterizations have different performance due to different result sizes, the most definitive solution is to write a driver program that repeats the query several times with random (but realistic) parameterizations, and hopes that the parameter-induced variation averages out between your tuning settings.  This is a pain, but when I have had to resort to it I generally came to wish I had to done it sooner.  This is better than doing each query from a cold cache, because in the real production situation you are unlikely to have a fully cold cache.  Certain parts of the data will be in common to all parameterizations, and that part will be "hot" enough to always be in the cache.