Re: [PERFORM] Help optimizing a slow index scan

2006-03-18 Thread Oleg Bartunov
I may be wrong but we in astronomy have several sky indexing schemes, which allows to effectively use classical btree index. See http://www.sai.msu.su/~megera/oddmuse/index.cgi/SkyPixelization for details. Sergei Koposov has developed Q3C contrib module for PostgreSQL 8.1+ and we use it with

Re: [PERFORM] planner with index scan cost way off actual cost, advices to tweak cost constants?

2006-03-18 Thread Guillaume Smet
Guillaume, On 17 Mar 2006 11:09:50 +0100, Guillaume Cottenceau wrote: Reading the documentation and postgresql list archives, I have run ANALYZE right before my tests, I have increased the statistics target to 50 for the considered table; my problem is that the index scan cost reported by

[PERFORM] n00b autovacuum question

2006-03-18 Thread Antoine
Hi, I have enabled the autovacuum daemon, but occasionally still get a message telling me I need to run vacuum when I access a table in pgadmin. Is this normal? Should I use scripts instead of the daemon? Would posting config options make this a much more sensible question? Cheers Antoine -- This

[PERFORM] database model tshirt sizes

2006-03-18 Thread NbForYou
Hello, Does anybody know how to build a database model to include sizes for rings, tshirts, etc? the current database is built like: table product = productid int8 PK productname charvar(255) quantity int4 what i want now is that WHEN (not all products have multiple sizes)

Re: [PERFORM] n00b autovacuum question

2006-03-18 Thread Matthew T. O'Connor
More detail please. It sounds like you running 8.1 and talking about the integrated autovacuum is that correct? Also, what is the message specifically from pgadmin? Matt Antoine wrote: Hi, I have enabled the autovacuum daemon, but occasionally still get a message telling me I need to run

Re: [PERFORM] n00b autovacuum question

2006-03-18 Thread Andreas Pflug
Antoine wrote: Hi, I have enabled the autovacuum daemon, but occasionally still get a message telling me I need to run vacuum when I access a table in pgadmin. pgAdmin notices a discrepancy between real rowcount and estimated rowcount and thus suggests to run vacuum/analyze; it won't examine

Re: [PERFORM] PostgreSQL and Xeon MP

2006-03-18 Thread Kenneth Marshall
On Thu, Mar 16, 2006 at 11:45:12AM +0100, Guillaume Smet wrote: Hello, We are experiencing performances problem with a quad Xeon MP and PostgreSQL 7.4 for a year now. Our context switch rate is not so high but the load of the server is blocked to 4 even on very high load and we have 60% cpu

Re: [PERFORM] Help optimizing a slow index scan

2006-03-18 Thread Evgeny Gridasov
Try contrib/btree_gist. I've tried that one, but for my case it didn't help much. The performance was almost equal or even slower than built-in btree. On Fri, 17 Mar 2006 08:53:44 -0700 Dan Harris [EMAIL PROTECTED] wrote: Dan Harris wrote: Markus Bertheau wrote: Have you tried using a GIST

Re: [PERFORM] firebird X postgresql 8.1.2 windows, performance comparison

2006-03-18 Thread Chris Travers
Andre Felipe Machado wrote: Postgresql uses around 30% cpu and hard disk heavily (not so as vacuum) at all executions. Firebird uses around 40% cpu and hard disk heavily at the first execution. The second execution uses around 60% cpu and **NO** disk activity. The previously cited query

Re: [PERFORM] planner with index scan cost way off actual cost,

2006-03-18 Thread Mark Kirkwood
Guillaume Cottenceau wrote: SET random_page_cost = 2; SET effective_cache_size = 1; EXPLAIN SELECT * FROM sent_messages WHERE date '2005-09-01' AND date '2005-09-19'; QUERY PLAN

Re: [PERFORM] Help optimizing a slow index scan

2006-03-18 Thread Oleg Bartunov
On Fri, 17 Mar 2006, Evgeny Gridasov wrote: Try contrib/btree_gist. contrib/btree_gist does nothing more than built-in btree - it's just an support for multicolumn GiST indices. I've tried that one, but for my case it didn't help much. The performance was almost equal or even slower than