On Mon, Aug 08, 2005 at 08:58:26PM -0400, Tom Lane wrote:
> I'd be interested to see results from other people using 7.4.* too.
I just built 7.4.1 on FreeBSD 4.11-STABLE and ran your test:
test=# explain analyze select rtmessagestate.* from rtmessagestate,connection
where (connection_registry_id
Qingqing Zhou wrote:
<[EMAIL PROTECTED]> writes
so, if I do a qry like "EXPLAIN ANALYZE select * from pridecdr where
idsede=8977758488" it tooks a lot of time before i get back any result:
Index Scan using prd_id_sede on pridecdr (cost=0.00..699079.90
rows=181850 width=138) (actual time=51.2
<[EMAIL PROTECTED]> writes
>
>
> so, if I do a qry like "EXPLAIN ANALYZE select * from pridecdr where
> idsede=8977758488" it tooks a lot of time before i get back any result:
>
> Index Scan using prd_id_sede on pridecdr (cost=0.00..699079.90
> rows=181850 width=138) (actual time=51.241..483068.2
On Mon, Aug 08, 2005 at 08:58:26PM -0400, Tom Lane wrote:
> Hmph. There is something really strange going on here. I tried to
> duplicate your problem in 7.4.*, thus:
PostgreSQL 7.4.7 (Debian sarge):
regression=# explain analyze select rtmessagestate.* from
rtmessagestate,connection where (c
Rhett Garber <[EMAIL PROTECTED]> writes:
> This is postgres 7.4.1
> All the rows involved are integers.
Hmph. There is something really strange going on here. I tried to
duplicate your problem in 7.4.*, thus:
regression=# create table rtmessagestate(id int, f1 char(6));
CREATE TABLE
regression=
Kari Lavikka <[EMAIL PROTECTED]> writes:
> Disk configurations looks something like this:
>sda: data (10 spindles, raid10)
>sdb: xlog & clog (2 spindles, raid1)
>sdc: os and other stuff
That's definitely wrong. Put clog on the data disk. The entire point
of giving xlog its own spindl
On Mon, 8 Aug 2005, Tom Lane wrote:
What that sounds like to me is a machine with inadequate disk I/O bandwidth.
Your earlier comment that checkpoint drives the machine into the ground
fits right into that theory, too. You said there is "almost no IO-wait"
but are you sure you are measuring that
This is postgres 7.4.1
All the rows involved are integers.
Thanks,
Rhett
On 8/5/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> Rhett Garber <[EMAIL PROTECTED]> writes:
> > Hash Join (cost=5.96..7.04 rows=1 width=14) (actual
> > time=10.591..10.609 rows=1 loops=1)
> >Hash Cond: ("outer".id = "in
Kari Lavikka <[EMAIL PROTECTED]> writes:
> We are having performance problems with some smaller tables and very
> simple queries. For example:
> SELECT u.uid, u.nick, extract(epoch from uc.stamp) AS stamp FROM
> user_channel uc INNER JOIN users u USING (uid) WHERE channel_id = 281321
> AND u.st
Actually I modified postgresql.conf a bit and there isn't commit delay any
more. That didn't make noticeable difference though..
Workload is generated by a website with about 1000 dynamic page views a
second. Finland's biggest site among youths btw.
Anyway, there are about 70 tables and her
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
>> Kari Lavikka <[EMAIL PROTECTED]> writes:
>>> samples %symbol name
>>> 13513390 16.0074 AtEOXact_CatCache
>>
>> That seems quite odd --- I'm not used to seeing that function at the top
>> of a profile. What is the workload being profiled, e
> Kari Lavikka <[EMAIL PROTECTED]> writes:
> > samples %symbol name
> > 13513390 16.0074 AtEOXact_CatCache
>
> That seems quite odd --- I'm not used to seeing that function at the
top
> of a profile. What is the workload being profiled, exactly?
He is running a commit_delay of 8.
Patrick Hatcher <[EMAIL PROTECTED]> writes:
> Here's the table layout. It's the first time I noticed this, but there
> is a PK on the cus_nbr and an index. Does really need to be both and
> could this be causing the issue? I thought that if a primary key was
> designated, it was automatically
Kari Lavikka <[EMAIL PROTECTED]> writes:
> samples %symbol name
> 13513390 16.0074 AtEOXact_CatCache
That seems quite odd --- I'm not used to seeing that function at the top
of a profile. What is the workload being profiled, exactly?
regards, tom lane
-
Hi!
Oprofile looks quite interesting. I'm not very familiar with postgresql
internals, but here's some report output:
CPU: AMD64 processors, speed 2190.23 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit
mask of 0x00 (No unit mask) count 10
samp
15 matches
Mail list logo
