On Wed, 25 Aug 2004, Richard Huxton wrote:
Index Scan using trptserc on trans (cost=0.00..465.10 rows=44 width=118)
Index Cond: (trn_patno = 19)
Filter: ((trn_old_date = '1994-08-23'::date) AND (trn_old_date =
'2004-08-23'::date) AND (trn_bill_inc = 'B'::bpchar))
(687 rows)
Josh,
Le Jeudi 26 Août 2004 01:50, Josh Berkus a écrit :
The request takes about 4 seconds ... I have about 1 400 000 records in
article and 36 000 records in site table ... it's a Bi-Pentium III 933
MHz server with 1 Gb memory ... I'm using Postgresql 7.4.5
For me this result is very
Dennis Bjorklund wrote:
On Wed, 25 Aug 2004, Richard Huxton wrote:
These queries are different. The first returns 687 rows and the second
713 rows.
The 687 and 713 are the number of rows in the plan, not the number of rows
the queries return.
D'OH! Thanks Dennis
--
Richard Huxton
Archonet
Tom, your suspicions were correct - ANALYZE was not being run.
I run vacuumdb via a cron script during off hours. After checking the
scripts on both systems, I found that on the system that was not functioning
correctly that the '-z' (analyze) command line option to vacuumdb was
missing. After
Just starting to work with one now, so I'll let people know what I
find. There has been
some talk that the XServe RAID seems more optimized for streaming
applications rather than
heavy random-access type applications, which really wouldn't surprise
me given where they
probably expect to sell
Bill Footcow wrote:
...
I have done a simple request, looking for title or description having Postgres
inside order by rank and date, like this :
SELECT a.title, a.id, a.url, to_char(a.r_date, 'DD/MM/ HH24:MI:SS') as dt,
s.site_name, s.id_site, case when exists (select id_user from
I am using a simple PostgreSQL 7.3 database in a soft-realtime
application.
I have a problem where an update on a record within a (fully indexed)
table containing less than ten records needs to occur as fast as
possible.
Immediately after performing a vaccum, updates take upto 50 milliseconds
to
How do vendors actually implement auto-clustering? I assume they move
rows around during quiet periods or have lots of empty space in each
value bucket.
---
J. Andrew Rogers wrote:
On Tue, 2004-08-24 at 22:28, Mischa
Neil,
I am using a simple PostgreSQL 7.3 database in a soft-realtime
application.
Then you're not going to like the answer I have for you, see below.
I have a problem where an update on a record within a (fully indexed)
table containing less than ten records needs to occur as fast as
On Thu, 2004-08-26 at 11:18, Bruce Momjian wrote:
How do vendors actually implement auto-clustering? I assume they move
rows around during quiet periods or have lots of empty space in each
value bucket.
As far as I know, Oracle does it by having a B-Tree organized heap (a
feature introduced
Actually you are both are right and wrong. The XRaid uses FibreChannel
to communicate to the host machine(s). The Raid controller is a
FibreChannel controller. After that there is a FibreChannel to
UltraATA conversion for each drive, separate ATA bus for each drive.
What I am curious about is
How do vendors actually implement auto-clustering? I assume
they move
rows around during quiet periods or have lots of empty space in each
value bucket.
As far as I know, Oracle does it by having a B-Tree organized heap (a
feature introduced around v8 IIRC), basically making the primary key
Le Jeudi 26 Août 2004 19:48, Josh Berkus a écrit :
Herve'
(cost=0.00..4052.84 rows=1351 width=166) (actual time=109.766..5415.108
rows=139 loops=1)
Index Cond: (idxfti @@ '\'postgresql\''::tsquery)
Filter: (idxfti @@ '\'postgresql\''::tsquery)
Kevin Barnard [EMAIL PROTECTED] writes:
Actually you are both are right and wrong. The XRaid uses
FibreChannel to communicate to the host machine(s). The Raid
controller is a FibreChannel controller. After that there is a
FibreChannel to UltraATA conversion for each drive,
Doug McNaught wrote:
Kevin Barnard [EMAIL PROTECTED] writes:
Actually you are both are right and wrong. The XRaid uses
FibreChannel to communicate to the host machine(s). The Raid
controller is a FibreChannel controller. After that there is a
FibreChannel to UltraATA conversion for
On Aug 26, 2004, at 3:54 PM, Doug McNaught wrote:
Kevin Barnard [EMAIL PROTECTED] writes:
Actually you are both are right and wrong. The XRaid uses
FibreChannel to communicate to the host machine(s). The Raid
controller is a FibreChannel controller. After that there is a
On Thu, 2004-08-26 at 12:30, Magnus Hagander wrote:
Almost the same for MSSQL. The clustered index is always forced unique.
If you create a non-unique clustered index, SQLServer will internally
pad it with random (or is it sequential? Can't remember right now) data
to make each key unique. The
Bruce Momjian wrote:
How do vendors actually implement auto-clustering? I assume they move
rows around during quiet periods or have lots of empty space in each
value bucket.
---
IIRC informix doesn't have it, and you have to
FWIW,
Informix does allow the fragmentation of data over named dbspaces by round-robin and
expression; this is autosupporting as long as the dba keeps enough space available.
You may also fragment the index although there are some variations depending on type
of Informix (XPS, etc.); this is
Updated TODO item:
o Automatically maintain clustering on a table
This would require some background daemon to maintain clustering
during periods of low usage. It might also require tables to be only
paritally filled for easier reorganization. It also might
Bruce Momjian [EMAIL PROTECTED] writes:
Updated TODO item:
o Automatically maintain clustering on a table
This would require some background daemon to maintain clustering
during periods of low usage. It might also require tables to be only
paritally
OK, new wording:
o Automatically maintain clustering on a table
This might require some background daemon to maintain clustering
during periods of low usage. It might also require tables to be only
paritally filled for easier reorganization. Another idea would
22 matches
Mail list logo
