Re: [PERFORM] severe performance issue with planner

2004-03-28 Thread Tom Lane
Eric Brown [EMAIL PROTECTED] writes: Here's the query as I have changed it now: Now that you've switched to JOIN syntax, you can cut the planning time to nil by setting join_collapse_limit to 1. See http://www.postgresql.org/docs/7.4/static/explicit-joins.html regards,

Re: [PERFORM] column size too large, is this a bug?

2004-03-28 Thread Josh Berkus
Andrew, I used to use the connect-by patch, but have since rewritten everything to use a nested set model. Cool! You're probably the only person I know other than me using nested sets in a production environment. -- Josh Berkus Aglio Database Solutions San Francisco

Re: [PERFORM] postgres eating CPU on HP9000

2004-03-28 Thread Josh Berkus
Marcus, We are experiencing exactly the same problem here, and we use 7.4 on Linux/i386 SMP (2 processors). Our databases does even more access: about 30k selects per hour, 10k updates and inserts per hour Vacuum analyze is done daily. What is your max_fsm_pages setting? If you are

Re: [PERFORM] column size too large, is this a bug?

2004-03-28 Thread Andrew Rawnsley
Well, I don't know if I would use it in an insert-heavy environment (at least the way I implemented it), but for select-heavy stuff I don't know why you would want to use anything else. Hard to beat the performance of a simple BETWEEN. On Mar 28, 2004, at 2:25 PM, Josh Berkus wrote: Andrew, I