Re: [PERFORM] PostgreSQL 8.4 performance tuning questions

2009-08-04 Thread Merlin Moncure
On Mon, Aug 3, 2009 at 5:30 PM, PFCli...@peufeu.com wrote: lzo is much, much, (much) faster than zlib.  Note, I've tried several decompression speed is even more awesome... times to contact the author to get clarification on licensing terms and have been unable to get a response. lzop and

Re: [PERFORM] select count(idn) is slow (Seq Scan) instead of Bitmap Heap.. why?

2009-08-04 Thread Robert Haas
2009/8/2 Adam PAPAI w...@wooh.hu: Hello, I have a problem with an inner join + count(). my query is: explain analyze select k.idn,k.kerdes_subject,k.kerdes_text,u.vezeteknev,u.keresztnev,u.idn as user_id, kg.kategoria_neve, count(v.idn) FROM kategoriak as kg INNER JOIN kerdesek as k

Re: [PERFORM] Query help

2009-08-04 Thread Subbiah Stalin-XCGF84
Thanks for the response kevin. DB size is about 30G. Bloat could have been due to recent load testing that was done. Autovaccum wasn't aggressive enough to catch up with load testing. I will rebuild those indexes if possible reload the table itself as they are bloated too. Sure I will collect

Re: [PERFORM] PostgreSQL 8.4 performance tuning questions

2009-08-04 Thread Scott Carey
On 8/4/09 8:30 AM, Alvaro Herrera alvhe...@commandprompt.com wrote: Merlin Moncure escribió: On Mon, Aug 3, 2009 at 5:30 PM, PFCli...@peufeu.com wrote: lzo is much, much, (much) faster than zlib.  Note, I've tried several decompression speed is even more awesome... times to contact

Re: [PERFORM] PostgreSQL 8.4 performance tuning questions

2009-08-04 Thread Tom Lane
Scott Carey sc...@richrelevance.com writes: There are a handful of other compression algorithms very similar to LZO in performance / compression level under various licenses. LZO is just the best known and most widely used. And after we get done with the license question, we need to ask about

[PERFORM] postgresql and syslog

2009-08-04 Thread Ibrahim Harrani
Hi, I am using postgresql 8.3 with FreeBSD. FreeBSD is using syslog by default for postgresql logs. I would like to disable syslog in postgresql.conf. Does this change increase the performance? What is the impact of using syslog on postgresql performance? Thanks. -- Sent via pgsql-performance

Re: [PERFORM] GiST, caching, and consistency

2009-08-04 Thread Robert Haas
On Tue, Aug 4, 2009 at 12:06 PM, Matthew Wakelingmatt...@flymine.org wrote: I'm seeing an interesting phenomenon while I'm trying to performance-optimise a GiST index. Basically, running a performance test appears to be the same thing as running a random number generator. For example, here

[PERFORM] CHECK constraint fails when it's not supposed to

2009-08-04 Thread Richard Yen
Hi All, I encountered an odd issue regarding check constraints complaining when they're not really violated. For this particular machine, I am running 8.3.7, but on a machine running 8.3.5, it seems to have succeeded. I also upgraded a third machine from 8.3.5 to 8.3.7, and the query

Re: [PERFORM] GiST, caching, and consistency

2009-08-04 Thread Greg Stark
On Tue, Aug 4, 2009 at 11:56 PM, Robert Haasrobertmh...@gmail.com wrote: Beats me.  It looks like the first few queries are pulling stuff into cache, and then after that it settles down, but I'm not sure why it takes 5 repetitions to do that.  Is the plan changing? Yeah, we're just guessing

Re: [PERFORM] CHECK constraint fails when it's not supposed to

2009-08-04 Thread Greg Stark
On Tue, Aug 4, 2009 at 5:49 PM, Richard Yend...@richyen.com wrote: The data reads: tii=# select date_start, date_end, term_length, '2009-09-03 05:38:24.030331-07'::timestamptz - date_start AS new_term_length from m_class where id = 2652020;         date_start          |          date_end    

[PERFORM] CHECK constraint fails when it's not supposed to

2009-08-04 Thread richyen
Hi All, I encountered an odd issue regarding check constraints complaining when they're not really violated. For this particular machine, I am running 8.3.7, but on a machine running 8.3.5, it seems to have succeeded. I also upgraded a third machine from 8.3.5 to 8.3.7, and the query succeeded

Re: [PERFORM] SQL select query becomes slow when using limit (with no offset)

2009-08-04 Thread Kees van Dieren
Hi Folks, Thanks for your response. I have added the following index (suggested by other post): CREATE INDEX events_events_cleared_eventtype ON events_events USING btree (eventtype_id, cleared) WHERE cleared = false; Also with columns in reversed order. No changes in response time