On 8/29/06, Willo van der Merwe <[EMAIL PROTECTED]> wrote:
and it has 743321 rows and a explain analyze select count(*) from
property_values;
you have a number of options:
1. keep a sequence on the property values and query it. if you want
exact count you must do some clever locking however
On Tue, 2006-08-29 at 15:52 +0200, Willo van der Merwe wrote:
> (cost=0.00..51848.56 rows=1309356 width=0)
It is going through way more number of rows than what is returned by the
count(*).
It appears that you need to VACUUM the table (not VACUUM ANALYZE).
---(end of bro
On Aug 29, 2006, at 7:52 AM, Willo van der Merwe wrote: Hi, We're running PostgreSQL 8.1.4 on CentOS 4 (Linux version 2.6.9-34.0.1.ELsmp). Hardware specs: 2x AMD Dual-Core Opteron 270 Italy 1Ghz HT 2 x 1MB L2 Cache Socket 940
4 GB Registered ECC PC3200 DDR RAM
SuperMicro Server-Class 1U AS1020S
Hi Jignesh,
Thank you for my reply.
I have the setting just like what you described:
wal_sync_method = fsyncwal_buffers = 128checkpoint_segments = 128bgwriter_all_percent = 0bgwriter_maxpages = 0
I ran the dtrace script and found the following:
During the i/o busy time, there are postgres processe
am Tue, dem 29.08.2006, um 16:55:11 +0200 mailte Willo van der Merwe folgendes:
> >>4 1/2 seconds for a count(*) ? This seems a bit rough - is there anything
> >>else
> >>
> >
> >Because of MVCC.
> >http://www.thescripts.com/forum/thread173678.html
> >http://www.varlena.com/GeneralBits/120.ph
4 1/2 seconds for a count(*) ?
Is this a real website query ? Do you need this query ?
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Also to answer your real question:
DTrace On Solaris 10:
# dtrace -s /usr/demo/dtrace/whoio.d
It will tell you the pids doing the io activity and on which devices.
There are more scripts in that directory like iosnoop.d, iotime.d and others which also will give
other details like file accesse
Joshua D. Drake wrote:
4 1/2 seconds for a count(*) ? This seems a bit rough - is there
anything else I can try to optimize my Database? You can imagine that
slightly more complex queries goes out the roof.
Well a couple of things.
1. You put all your money in the wrong place.. 1 hard drive
Did you increase the checkpoint segments and changed the default WAL lock
method to fdsync?
http://blogs.sun.com/jkshah/entry/postgresql_on_solaris_better_use
Try fdsync instead of fysnc as mentioned in the entry.
Regards,
Jignesh
Junaili Lie wrote:
Hi everyone,
We have a postgresql 8.1 ins
4 1/2 seconds for a count(*) ? This seems a bit rough - is there
anything else I can try to optimize my Database? You can imagine that
slightly more complex queries goes out the roof.
Well a couple of things.
1. You put all your money in the wrong place.. 1 hard drive!!??!!
2. What is your m
am Tue, dem 29.08.2006, um 15:52:50 +0200 mailte Willo van der Merwe folgendes:
> and it has 743321 rows and a explain analyze select count(*) from
> property_values;
> QUERY
> PLAN
>
Hi,
We're running PostgreSQL 8.1.4 on CentOS 4 (Linux version
2.6.9-34.0.1.ELsmp). Hardware specs:
2x AMD Dual-Core Opteron 270 Italy 1Ghz HT 2 x 1MB L2 Cache Socket 940
4 GB Registered ECC PC3200 DDR RAM
SuperMicro Server-Class 1U AS1020S series system
Dual-channel Ultra320 SCSI controller
1
am Tue, dem 29.08.2006, um 12:51:27 +0530 mailte Vanitha Jaya folgendes:
> Hi Friends,
>
> I have one doubt in LIMIT & OFFSET clause operation.
> I have a table "test_limit", and it contain,
First of all, you can use EXPLAIN ANALYSE for such tasks!
test=*# explain analyse select * from
Hi Friends,
I have one doubt in LIMIT & OFFSET clause operation.
I have a table "test_limit", and it contain,
SELECT * from test_limit;
s_no | name
--+-
1 | anbarasu
8 | egambaram
12 | jyothi
6 | mahalakshmi
4 | maheswari
2 | manju
5 | ramku
14 matches
Mail list logo
