Re: [PERFORM] PostgreSQL 8.4 performance tuning questions

On Mon, Aug 3, 2009 at 5:30 PM, PFC 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 the

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

2009/8/2 Adam PAPAI : > 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] PostgreSQL 8.4 performance tuning questions

Merlin Moncure escribió: > On Mon, Aug 3, 2009 at 5:30 PM, PFC 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 un

Re: [PERFORM] Query help

"Subbiah Stalin-XCGF84" wrote: > Server has 32G memory and it's a dedicated to run PG and no other > application is sharing this database. It's not likely to help with this particular problem, but it's generally best to start from a position of letting the optimizer know what it's really got f

[PERFORM] GiST, caching, and consistency

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 I'm running the same statement eight times in quick succession: modmine_ove

Re: [PERFORM] Query help

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 nec

Re: [PERFORM] PostgreSQL 8.4 performance tuning questions

On 8/4/09 8:30 AM, "Alvaro Herrera" wrote: > Merlin Moncure escribió: >> On Mon, Aug 3, 2009 at 5:30 PM, PFC 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 cl

Re: [PERFORM] PostgreSQL 8.4 performance tuning questions

Scott Carey 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 patents. The compres

[PERFORM] postgresql and syslog

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 m

Re: [PERFORM] GiST, caching, and consistency

On Tue, Aug 4, 2009 at 12:06 PM, Matthew Wakeling 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 I'm running the s

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

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 suc

Re: [PERFORM] GiST, caching, and consistency

On Tue, Aug 4, 2009 at 11:56 PM, Robert Haas 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 without the explain a

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

On Tue, Aug 4, 2009 at 5:49 PM, Richard Yen 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

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)

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 noti