Re: [PERFORM] disabling an index without deleting it?

(potentially) be modifying the index, like an UPDATE or an INSERT, or actual transaction commit. If none of these occur and the transaction is rollbacked, the exclusive lock doesn't have to be taken at all. Markus -- Markus Bertheau Blog: http://www.bluetwanger.de/blog/ ---(end

Re: [PERFORM] disabling an index without deleting it?

2008/2/27, Scott Marlowe [EMAIL PROTECTED]: On Tue, Feb 26, 2008 at 10:48 PM, Tom Lane [EMAIL PROTECTED] wrote: Markus Bertheau [EMAIL PROTECTED] writes: 2008/2/27, Tom Lane [EMAIL PROTECTED]: No, what makes you think that? The index won't change at all in the above example

[PERFORM] Index Scan Backward + check additional condition before heap access

Hi, (PostgreSQL 8.3) I'm trying to optimize one of the most often used queries in our system: (Full minimized pastable schema and data below.) create table feeds_users ( user_id int references users(id) not null, feed_id int references feeds(id) not null, unique(user_id, feed_id)

Re: [PERFORM] Postmaster using only 4-5% CPU

The low end server by chance doesn't have an IDE disk that lies about write completion, or a battery backed disk controller? Try disabling fsync on the new server to get comparable figures. Markus Bertheau 2006/3/21, Edoardo Serra [EMAIL PROTECTED]: Hi all, I'm having a very strange

Re: [PERFORM] Bad plan after vacuum analyze

query_section.sql ... correct plan ... Total runtime: 0.555 ms Given Tom's analysis, how can increasing the stats target change which plan is chosen? -- Markus Bertheau [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part

[PERFORM] recovery after long delete

will go through the in-progress txns and mark them as aborted. That's all the recovery in this case. All rows are still there. O(1). How does oracle do that? Has all this something to do with mvcc? Why does it take oracle so long to recover? Thanks Markus -- Markus Bertheau [EMAIL PROTECTED

[PERFORM] pl/pgsql faster than raw SQL?

-- Markus Bertheau [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [PERFORM] psql large RSS (1.6GB)

) (actual time=9.985..87.364 rows=2280 loops=1) Total runtime: 130944.586 ms You should run ANALYZE on your database once in a while. -- Markus Bertheau [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose

Re: [PERFORM] can't handle large number of INSERT/UPDATEs

Turns out the man page of vmstat in procps was changed on Oct 8 2002: http://cvs.sourceforge.net/viewcvs.py/procps/procps/vmstat.8?r1=1.1r2=1.2 in reaction to a debian bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=157935 -- Markus Bertheau [EMAIL PROTECTED

Re: [pgsql-advocacy] [PERFORM] MySQL vs PG TPC-H benchmarks

hundred meg to work in. (You don't want sort_mem that big normally, because there may be many sorts happening in parallel, but in a data-loading context there'll just be one active sort.) Doesn't this provide a reason for CREATE INDEX not to honour sort_mem? -- Markus Bertheau [EMAIL PROTECTED

Re: [PERFORM] sunquery and estimated rows

, 17.04.2004, 01:45, Tom Lane : The planner sees that as where scope = some complicated expression and falls back to a default estimate. It won't simplify a sub-select to a constant. (Some people consider that a feature ;-).) Why? Thanks -- Markus Bertheau [EMAIL PROTECTED

Re: [PERFORM] Slow join using network address function

=189.00..308.00 rows=11900 width=11) - Seq Scan on clients_commercial cc (cost=0.00..189.00 rows=11900 width=11) To help you, we need EXPLAIN ANALYZE, not just EXPLAIN. Thanks! He said he cancelled the query. -- Markus Bertheau [EMAIL PROTECTED