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
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
"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) (a
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 speci
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
child_1
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 start_
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
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
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, it
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 b
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 th
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
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 comman
[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
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
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
;
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 of
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
18 matches
Mail list logo