Re: [PERFORM] Read only transactions - Commit or Rollback
Markus Schaber writes: As I said, there usually are no writing transactions on the same database. Btw, there's another setting that might make a difference: Having ACID-Level SERIALIZABLE or READ COMMITED? Well, if nonrepeatable or phantom reads would pose a problem because of those occasional writes, you wouldn't be considering autocommit for performance reasons either, would you? regards, Andreas -- ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PERFORM] Index not used with prepared statement
Guido Neitzer schrob: I have a performance problem with prepared statements (JDBC prepared statement). This query: PreparedStatement st = conn.prepareStatement(SELECT id FROM dga_dienstleister WHERE plz like '45257'); does use an index. This query: String plz = 45257; PreparedStatement st = conn.prepareStatement(SELECT id FROM dga_dienstleister WHERE plz like ?); st.setString(1, plz); does NOT use an index. As it should in the end result in absolutely the same statement, the index should be used all the time. I'm not perfectly sure, but since the index could only be used with a subset of all possible parameters (the pattern for like has to be left-anchored), I could imagine the planner has to avoid the index in order to produce an universal plan (the thing behind a prepared statement). Is there a reason you are using the like operator at all? IMO using the =-operator instead in your example should produce an index-using prepared statement. HTH Andreas -- ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
