> 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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
