[PERFORM] Inaccurate GiST Index Cost Causes DB Contention

Heap Fetches: 0 Planning time: 0.521 ms Execution time: 32.577 ms (11 rows) Does anyone have any ideas on helping to track down issues with contention? I’m not seeing any locks, so I’m thinking it’s related to these queries taking longer and stacking up on top of each other.

Re: [PERFORM] long running query running too long

tables, however, you inherently have to go through the entire table. If anyone can clarify this, that'd be great. -- PC Drew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [PERFORM] long running query running too long

id) r, spk_tgp t WHERE r.tgpid = t.tgpid; -- PC Drew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [PERFORM] Disappointing performance in db migrated from MS SQL Server

h about 4 times the clock speed of the SQL Server box. For a chart of my results, please see http://leonout.com/pggraph.pdf for a graph of some test results. -- PC Drew Manager, Dominet IBSN 1600 Broadway, Suite 400 Denver, CO 80202 Phone: 303-984-4727 x107 Cell: 720-841-4543 Fax: 303-984-4730 Emai

Re: [PERFORM] slow database

false enable_nestloop = false enable_mergejoin = false enable_hashjoin = false WOAH, this is huge: random_page_cost = 10 Take a look at this page which goes through each option in the configuration file: http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html -- PC Drew Manager, Do

Re: [PERFORM] slow database

method? Try commenting all of these out or changing them to "true" instead of "false". -- PC Drew Manager, Dominet IBSN 1600 Broadway, Suite 400 Denver, CO 80202 Phone: 303-984-4727 x107 Cell: 720-841-4543 Fax: 303-984-4730 Email: [EMAIL PROTECTED]

Re: [PERFORM] select count(*) from anIntColumn where int_value = 0; is very slow

ribe and unsubscribe commands go to [EMAIL PROTECTED] -- PC Drew Manager, Dominet IBSN 1600 Broadway, Suite 400 Denver, CO 80202 Phone: 303-984-4727 x107 Cell: 720-841-4543 Fax: 303-984-4730 Email: [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subsc

Re: [PERFORM] another query optimization question

.id_job_profile in (select id_job_profile from unemployed) and t1.id_job_profile <> 911; results in a query plan result: What's the goal here? Are you trying to rank by how the int_value relates to each other? I'd like to know more about what kind of result you're trying to

Re: [PERFORM] (partial?) indexes, LIKE and NULL

My understanding is that having NULL values in an index breaks it completely. Meaning it won't be used in any query planning. Maybe I'm wrong though... -Original Message- From: Marinos J. Yannikos [mailto:[EMAIL PROTECTED] Sent: Tue 1/27/2004 12:26 PM To: [EMAIL PROTECTED] Cc:

Re: [PERFORM] Insert Times

0.02..0.02 rows=1 loops=1) Total runtime: 0.12 msec EXPLAIN ANALYZE INSERT INTO one (id, msg) VALUES (1, 'blah'); Result (cost=0.00..0.01 rows=1 width=0) (actual time=0.01..0.02 rows=1 loops=1) Total runtime: 0.12 msec -Original Message- From: Leeuw van der, Tim [mailto:[EMAIL PR

[PERFORM] Insert Times

I ran it twice to show that it is consistently repeatable) Now, of course this query isn't very interesting and shouldn't take very long, but it does illustrate the time difference between the first query and the last four. On my bigger insert query, it's takin