Thread

1. Re: SQL Performance Guidelines

   Lane Van Ingen <lvaningen@esncc.com> — 2005-01-26T18:27:08Z

   Clarification: I am talking about SQL coding practices in Postgres (how to write queries for best 
   results), not  tuning-related considerations (although that would be welcomed too).
    
   -----Original Message----- 
   From: pgsql-performance-owner@postgresql.org on behalf of Van Ingen, Lane 
   Sent: Wed 1/26/2005 11:44 AM 
   To: pgsql-performance@postgresql.org 
   Cc: 
   Subject: [PERFORM] SQL Performance Guidelines
   
   Does anybody know where I can lay my hands on some guidelines to get best SQL performance
   out of PostgreSQL? We are about to get into a project that will be new from the ground up (and\we are using Postgres for the first time). Would like to share some guidelines with developers on best practices
   in Postgres? Thanks for your help.
   
   ---------------------------(end of broadcast)---------------------------
   TIP 7: don't forget to increase your free space map settings
   
   

2. Re: SQL Performance Guidelines

   Dustin Sallings <dustin@spy.net> — 2005-01-27T08:02:29Z

   On Jan 26, 2005, at 10:27, Van Ingen, Lane wrote:
   
   > Clarification: I am talking about SQL coding practices in Postgres 
   > (how to write queries for best
   > results), not  tuning-related considerations (although that would be 
   > welcomed too).
   
   	Your question is a bit too vague.  At this point in your development, 
   all that really can be said is to understand relational database 
   concepts in general, and use explain a lot when developing queries.  
   (Oh, and don't forget to analyze before asking specific questions).
   
   > -----Original Message-----
   > From: pgsql-performance-owner@postgresql.org on behalf of Van Ingen, 
   > Lane
   > Sent: Wed 1/26/2005 11:44 AM
   > To: pgsql-performance@postgresql.org
   > Cc:
   > Subject: [PERFORM] SQL Performance Guidelines
   >
   > Does anybody know where I can lay my hands on some guidelines to get 
   > best SQL performance
   > out of PostgreSQL? We are about to get into a project that will be new 
   > from the ground up (and\we are using Postgres for the first time). 
   > Would like to share some guidelines with developers on best practices
   > in Postgres? Thanks for your help.
   >
   > ---------------------------(end of 
   > broadcast)---------------------------
   > TIP 7: don't forget to increase your free space map settings
   >
   >
   > ---------------------------(end of 
   > broadcast)---------------------------
   > TIP 7: don't forget to increase your free space map settings
   >
   --
   SPY                      My girlfriend asked me which one I like better.
   pub  1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
   |    Key fingerprint =  87 02 57 08 02 D0 DA D6  C8 0F 3E 65 51 98 D8 BE
   L_______________________ I hope the answer won't upset her. ____________
   
   
   

3. Re: SQL Performance Guidelines

   Mitch Pirtle <mitch.pirtle@gmail.com> — 2005-01-27T14:50:32Z

   On Thu, 27 Jan 2005 00:02:29 -0800, Dustin Sallings <dustin@spy.net> wrote:
   > 
   > On Jan 26, 2005, at 10:27, Van Ingen, Lane wrote:
   > 
   > > Clarification: I am talking about SQL coding practices in Postgres
   > > (how to write queries for best
   > > results), not  tuning-related considerations (although that would be
   > > welcomed too).
   > 
   >         Your question is a bit too vague.  At this point in your development,
   > all that really can be said is to understand relational database
   > concepts in general, and use explain a lot when developing queries.
   > (Oh, and don't forget to analyze before asking specific questions).
   
   I disagree - there are plenty of tricks that are PostgreSQL only, and
   many people on this list have that knowledge but it is not documented
   anywhere, or is hidden within thousands of mailing list posts.
   
   For example, IIRC when joining an integer column with a SERIAL column,
   you must expicitly cast it as an integer or the planner will not use
   the indexes, right? (This is a guess, as I remember reading something
   like this and thinking, "How in the world is someone supposed to
   figure that out, even with EXPLAIN?")
   
   There is another thread about how a query using a WHERE NOT NULL
   clause is faster than one without.
   
   These things are PostgreSQL specific, and documenting them would go a
   long way towards educating the switchover crowd.
   
   The closest thing I have seen to this is the PostgreSQL Gotchas page:
   
   http://sql-info.de/postgresql/postgres-gotchas.html
   
   HTH,
   
   -- Mitch
   
   

4. Re: SQL Performance Guidelines

   Christopher Kings-Lynne <chriskl@familyhealth.com.au> — 2005-01-27T15:19:41Z

   > For example, IIRC when joining an integer column with a SERIAL column,
   > you must expicitly cast it as an integer or the planner will not use
   > the indexes, right? (This is a guess, as I remember reading something
   > like this and thinking, "How in the world is someone supposed to
   > figure that out, even with EXPLAIN?")
   
   That's not true at all.  Perhaps you're thinking about BIGSERIAL and 
   int8 indexes - something that's been addressed in 8.0.
   
   Chris