On 28/08/06, Michal Taborsky - Internet Mall [EMAIL PROTECTED] wrote:
Markus Schaber napsal(a):
Hi, Michal,
Michal Taborsky - Internet Mall wrote:
When using this view, you are interested in tables, which have the
bloat column higher that say 2.0 (in freshly dump/restored/analyzed
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 | ramkumar
7 | sangeetha
11 | sasikala
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 mira
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
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
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
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
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
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
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.php
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
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
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
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.
14 matches
Mail list logo
