Tom Lane wrote:
Tatsuo Ishii [EMAIL PROTECTED] writes:
18% in s_lock is definitely bad :-(. Were you able to determine which
LWLock(s) are accounting for the contention?
Sorry for the delay. Finally I got the oprofile data. It's
huge(34MB). If you are interested, I can put
Title: Forcing using index instead of sequential scan?
I have been testing the performance of PostgreSQL using the simple tool found at http://benchw.sourceforge.net however I have found that all the queries it run execute with sequential scans. The website where the code runs has examples
More information from the query:-
explain analyze
SELECT
d0.dmth,
count(f.fval )
FROM
dim0 AS d0,
fact0 AS f
WHERE d0.d0key = f.d0key
AND d0.ddate BETWEEN '2010-01-01' AND '2010-12-28'
GROUP BY
d0.dmth
;
The tables have all been analysed.
I set the work_mem to 50 and it still doesn't use the index :-(
Regards
Robin
-Original Message-
From: Richard Huxton [mailto:[EMAIL PROTECTED]
Sent: 21 July 2006 12:54
To: Smith,R,Robin,XJE4JA C
Subject: Re: [PERFORM] Forcing using index instead
[EMAIL PROTECTED] wrote:
What is the best way to force the use of indexes in these queries?
Well, the brute-force method is to use SET enable_seqscan TO off, but if
you want to get to the bottom of this, you should look at or post the
EXPLAIN ANALYZE output of the offending queries.
--
Peter
Hello,
does anybody use OSDB benchmarks for postgres?
if not, which kind of bechmarks are used for postgres?
Thanks,
Denis.
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail
Robert Lor [EMAIL PROTECTED] writes:
I ran pgbench and fired up a DTrace script using the lwlock probes we've
added, and it looks like BufMappingLock is the most contended lock, but
CheckpointStartLocks are held for longer duration!
Those numbers look a bit suspicious --- I'd expect to see
On Fri, Jul 21, 2006 at 12:56:56AM -0700, Robert Lor wrote:
I ran pgbench and fired up a DTrace script using the lwlock probes we've
added, and it looks like BufMappingLock is the most contended lock, but
CheckpointStartLocks are held for longer duration!
Not terribly surprising given that
Hi,
Tom Lane schrieb:
Robert Lor [EMAIL PROTECTED] writes:
I ran pgbench and fired up a DTrace script using the lwlock probes we've
added, and it looks like BufMappingLock is the most contended lock, but
CheckpointStartLocks are held for longer duration!
Those numbers look a bit
Tom Lane wrote:
Those numbers look a bit suspicious --- I'd expect to see some of the
LWLocks being taken in both shared and exclusive modes, but you don't
show any such cases. You sure your script is counting correctly?
I'll double check to make sure no stupid mistakes were made!
Also,
On Fri, Jul 21, 2006 at 07:41:02 +,
Alaa El Gohary [EMAIL PROTECTED] wrote:
The following bug has been logged online:
The report below isn't a bug, its a performance question and should have
been sent to [EMAIL PROTECTED] I am redirecting replies there.
A query on the postgresql DB
I discussed this with a few members of #postgresql
freenode this morning. I'll keep it breif; [note: i have cleaned out columns not
relevant]
I have two tables, brands and models_brands. The
first has about 300 records, the later about 350,000 records. The number of
distinct brands in the
I have a case where I am partitioning tables based on a date range in
version 8.1.4. For example:
table_with_millions_of_records
interaction_id char(16) primary key
start_date timestamp (without timezone) - indexed
.. other columns
child_1 start_date = 2006-07-21 00:00:00
child_2
On Jul 21, 2006, at 12:17 PM, Kevin Keith wrote:
I have a case where I am partitioning tables based on a date range
in version 8.1.4. For example:
table_with_millions_of_records
interaction_id char(16) primary key
start_date timestamp (without timezone) - indexed
.. other columns
My post might have been a little premature - and I apologize for that.
I have figured out what was causing the problem:
1. Constraint exclusion was disabled. I re-enabled.
2. I found that using the now() function - and arbitrary interval will
produce a different execution plan that using a
Kevin McArthur [EMAIL PROTECTED] writes:
- Seq Scan on models_brands (cost=0.00..6411.89 rows=369489
width=4) (actual time=0.040..1352.997 rows=369489 loops=1)
...
- Index Scan using models_brands_brand on models_brands
(cost=0.00..862236.96 rows=369489 width=4) (actual
Tom,
On 7/21/06, Tom Lane [EMAIL PROTECTED] wrote:
It's really not possible for a full-table indexscan to be faster than a
seqscan, and not very credible for it even to be approximately as fast.
I suspect your second query here is the beneficiary of the first query
having fetched all the pages
Tom Lane wrote:
Also, it'd be interesting to count time spent holding shared lock
separately from time spent holding exclusive.
Tom,
Here is the break down between exclusive shared LWLocks. Do the
numbers look reasonable to you?
Regards,
-Robert
bash-3.00# time ./Tom_lwlock_acquire.d
18 matches
Mail list logo
