> This makes me wonder would it make any good to create additional column of Integer type and update it as data gets added and use this integer column for all ordering purposes for my sqls - or should I not hasitate using Date type straight into my sql for ordering? Keep in mind what Michael A. Jackson (among others) had to say on this: "The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet." For one thing, adding an extra column to your data would mean more data you need to cram in the cache as you query, so even if the *raw* integer versus date ordering is faster, the "optimization" could still be a net loss due to the fatter tuples. If you're willing to live with *only* integer-based dates, that could help, but that seems exceptionally painful and not worth considering unless you run into trouble. > Better yet, is there anyway I can verify impact of ordering on Date type vs. Integer type, apart from using \timing and explain plan? Remember to use explain analyze (and not just explain) when validating these sorts of things. Explain is really just a guess. Also remember to ensure that stats are up to date before you test this. --- Maciek Sakrejda | System Architect | Truviso 1065 E. Hillsdale Blvd., Suite 215 Foster City, CA 94404 (650) 242-3500 Main www.truviso.com -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
