Hi, I have just installed 8.0.0beta1 and I noticed
that some query are slower than 7.4.2 queries.
After:
pg_dump my_database >mydb.sql (from
7.4.2)
psql my_new_database
FULL VACUUM ANALYZE
***With the old db on 7.4.2***
explain analyze SELECT count(*) FROM "SNS_DATA"
WHERE "Data_Arri
Hi,
> For your "streaming" purposes I strongly recommend
> you do it in your
> application with the appropriate thread model. A
> relational database
> management system is not a multimedia cache.
That's actually what i plan to do with postgreSQL,
maybe tailor it to suit with a multimedia stream
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
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
> parital
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 requi
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 av
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 r
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.
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
FibreChann
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
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,
Magnus,
> IIRC, SQL Server always creates clustered indexes by default for primary
> keys.
I think that's a per-database setting; certainly the ones I admin do not.
However, since SQL Server orders its data pages, those data pages tend to be
in the order of the primary key regardless if there i
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\''::ts
>> 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 p
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
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 introduce
Bruce,
> 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.
That's how SQL Server does it. In old versions (6.5) you had to manually
send commands to update the cluster, same as PG. Als
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
> p
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 Sand
> Immediately after performing a vaccum, updates take upto 50
> milliseconds to occur, however the update performance
> degrades over time, such that after a few hours of continuous
> updates, each update takes about half a second. Regular
> vacuuming improves the performance temporarily, but d
On Tue, 2004-08-24 at 22:28, Mischa Sandberg wrote:
> I see that PG has a one-shot CLUSTER command, but doesn't support
> continuously-updated clustered indexes.
>
> What I infer from newsgroup browsing is, such an index is impossible,
> given the MVCC versioning of records (happy to learn I'm wro
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
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
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)
>From this, it looks like your FTI index isn't fitting
Oops. My bad.
They must really want to sell those things if they're making them
completely platform independent...
On Aug 26, 2004, at 11:13 AM, Tore Halset wrote:
On Aug 26, 2004, at 14:07, Andrew Rawnsley wrote:
The unit itself is built very well, and the admin tools are very good
(OS X only,
On Aug 26, 2004, at 14:07, Andrew Rawnsley wrote:
The unit itself is built very well, and the admin tools are very good
(OS X only, though). It and the
The admin tools are supposed to work cross platform. From Apples
website: "This Java-based application provides an intuitive interface
for creat
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 mos
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 c
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 Lt
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 v
30 matches
Mail list logo
