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
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 =
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
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
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
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
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
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
---
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
> -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
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
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"
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
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
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
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
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
> "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
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
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
-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
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
23 matches
Mail list logo
