Gaetano Mendola wrote:
> | Right. My point was that non-full fill is valuable for us only when
> | doing clustering, while for Oracle it is a win even in non-cluster cases
> | because of the way they update in place.
>
> Don't you think this will permit also to avoid extra disk seek and cache
> i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruce Momjian wrote:
| Gaetano Mendola wrote:
|
|>Tom Lane wrote:
|>
|> > Bruce Momjian <[EMAIL PROTECTED]> writes:
|> >
|> >>Agreed. What I am wondering is with our system where every update gets
|> >>a new row, how would this help us? I know we try
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
>>Agreed. What I am wondering is with our system where every update gets
>>a new row, how would this help us? I know we try to keep an update on
>>the same row as the original, but is there any significant performance
>>benefit to doin
I could force Postgres to use the best index by removing condition "msgstatus = CAST(
0 AS
smallint );" from WHERE clause & set enable_seqscan to off;
Total runtime in this case dropped from 1883 ms ( sequential reads ) to 1.598 ms (
best index ).
But unfortunatelly It does not resolve my proble
> "JB" == Josh Berkus <[EMAIL PROTECTED]> writes:
JB> Guys,
>> the XServe/XRaid comes with FibreChannel
JB> I stand corrected. That should help things some; it makes it more
JB> of a small tradeoff between performance and storage size for the
JB> drives.
it is fibre channel to the host. t
On Fri, 27 Aug 2004, Artimenko Igor wrote:
> 1. Sequential search and very high cost if set enable_seqscan to on;
> Seq scan on messageinfo ( cost=0.00..24371.30, rows =36802 )
>
> 2. Index scan but even bigger cost if set enable_seqscan to off;
> Index “messagesStatus” on messageinfo ( Cost=0.00
Greg Stark wrote:
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > but is there any significant performance benefit to doing that which would
> > offset the compaction advantage?
>
> Just as a side comment. Setting PCTFREE 0 PCTUSED 100 on tables that have no
> updates on them has an astonish
Bruce Momjian <[EMAIL PROTECTED]> writes:
> but is there any significant performance benefit to doing that which would
> offset the compaction advantage?
Just as a side comment. Setting PCTFREE 0 PCTUSED 100 on tables that have no
updates on them has an astonishingly big effect on speed. So the
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Agreed. What I am wondering is with our system where every update gets
> a new row, how would this help us? I know we try to keep an update on
> the same row as the original, but is there any significant performance
> benefit to doing that which would
Hi everybody!
Here is my queries:
1. explain SELECT * FROM messageinfo WHERE user_id = CAST( 2 AS BIGINT ) and
msgstatus = CAST(
0 AS smallint );
2. explain SELECT * FROM messageinfo WHERE messageinfo.user_id = 2::int8 and
msgstatus =
0::smallint;
In both cases Explain command shows:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Agreed. What I am wondering is with our system where every update gets
> a new row, how would this help us? I know we try to keep an update on
> the same row as the original, but is there any significant performance
> benefit to doing that which would o
Adi Alurkar wrote:
> IIRC it it to reduce the "overflow" of data or what oracle calls
> chained rows. i.e if a table has variable length columns and 10 rows
> get inserted into a datapage, if this datapage is full and one of the
> variable length field gets updated the row will now "overflow"
IIRC it it to reduce the "overflow" of data or what oracle calls
chained rows. i.e if a table has variable length columns and 10 rows
get inserted into a datapage, if this datapage is full and one of the
variable length field gets updated the row will now "overflow" into
another datapage, b
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Bruce Momjian
> Sent: Friday, August 27, 2004 1:27 PM
> To: Adi Alurkar
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PERFORM] Equivalent praxis to CLUSTERED INDEX?
>
>
>
> But what is the advantage o
But what is the advantage of non-full pages in Oracle?
---
Adi Alurkar wrote:
> Greetings,
>
> I am not sure if this applies only to clustering but for storage in
> general,
>
> IIRC Oracle has 2 parameters that can be s
Stefano,
> Hi, I have just installed 8.0.0beta1 and I noticed that some query are
> slower than 7.4.2 queries.
Seems unlikely. How have you configured postgresql.conf?DID you
configure it for the 8.0 database?
--
Josh Berkus
Aglio Database Solutions
San Francisco
---
Is it possible (to mix two threads) that you had CLUSTERed the table on the old
database in a way that retrieved the records in this query faster?
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Greetings,
I am not sure if this applies only to clustering but for storage in
general,
IIRC Oracle has 2 parameters that can be set at table creation :
from Oracle docs
PCTFREE integer :
Specify the percentage of space in each data block of the table, object
table OID index, or partition reser
Josh Berkus wrote:
> Bruce,
>
> What happened to the B-Tree Table patch discussed on Hackers ad nauseum last
> winter?
I don't remember that. The only issue I remember is sorting btree index
by heap tid on creation. We eventually got that into CVS for 8.0.
--
Bruce Momjian
Bruce,
What happened to the B-Tree Table patch discussed on Hackers ad nauseum last
winter?
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
I had FILLFACTOR in the TODO list until just a few months ago, but
because no one had discussed it in 3-4 years, I removed the item. I
have added mention now in the auto-cluster section because that actually
seems like the only good reason for a non-100% fillfactor. I don't
think our ordinary bt
7.4.2
> Aggregate (cost=46817.89..46817.89 rows=1 width=0) (actual time=401.216..401.217
> rows=1 loops=1)
>-> Index Scan using snsdata_codpar on "SNS_DATA" (cost=0.00..46817.22 rows=268
> width=0) (actual time=165.948..400.258 rows=744 loops=1)
> Index Cond: (("Cod_Par")::text =
Greg Stark wrote:
The discussions before talked about a mechanism to try to place new
> tuples as close as possible to the proper index position.
Means this that an index shall have a "fill factor" property, similar to
Informix one ?
From the manual:
The FILLFACTOR option takes effect only when yo
23 matches
Mail list logo
