Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > My wild guess is that deleting all index pointers for a removed index is
> > more-or-less the same cost as creating new ones for inserted/updated
> > page.
>
> Only if you are willing to make the removal process recalculate the
> inde
Bruce Momjian writes:
> I assume that for a vacuum that only hit pages indicated in the bitmap,
> it would still be necessary to do an index scan to remove the heap
> pointers in the index, right?
Given the current vacuum technology, yes. However, bearing in mind that
indexes should generally be
> > The bgwriter could "update" all columns of dead heap tuples in heap
> > pages to NULL and thus also gain free space without the need to
touch
> > the indexes.
> > The slot would stay used but it would need less space.
>
> Not unless it's running a transaction (consider TOAST updates).
Ok,
"Zeugswetter Andreas DAZ SD" <[EMAIL PROTECTED]> writes:
> The bgwriter could "update" all columns of dead heap tuples in heap
> pages
> to NULL and thus also gain free space without the need to touch the
> indexes.
> The slot would stay used but it would need less space.
Not unless it's running a
> > My wild guess is that deleting all index pointers for a removed
index
> > is more-or-less the same cost as creating new ones for
> > inserted/updated page.
>
> Only if you are willing to make the removal process
> recalculate the index keys from looking at the deleted tuple.
The bgwriter
On K, 2005-08-31 at 12:23 -0400, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > My wild guess is that deleting all index pointers for a removed index is
> > more-or-less the same cost as creating new ones for inserted/updated
> > page.
>
> Only if you are willing to make the remov
On Wed, 2005-08-31 at 16:50 +0900, Satoshi Nagayasu wrote:
> Simon Riggs wrote:
> >>4. Allow to repair fragmentation in each page.
> >>
> >>Because updates cause fragmentation in the page.
> >>
> >>So we need to keep large continuous free space in each page,
> >>if we want to get more effective on
Hannu Krosing <[EMAIL PROTECTED]> writes:
> My wild guess is that deleting all index pointers for a removed index is
> more-or-less the same cost as creating new ones for inserted/updated
> page.
Only if you are willing to make the removal process recalculate the
index keys from looking at the del
On K, 2005-08-31 at 10:33 -0400, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > On K, 2005-08-31 at 16:50 +0900, Satoshi Nagayasu wrote:
> >> VACUUM generates a huge load because it repaires all pages
> >> on the table file.
> >>
> >> I think (more light-weight) repairing on a sin
Hannu Krosing <[EMAIL PROTECTED]> writes:
> On K, 2005-08-31 at 16:50 +0900, Satoshi Nagayasu wrote:
>> VACUUM generates a huge load because it repaires all pages
>> on the table file.
>>
>> I think (more light-weight) repairing on a single page
>> is needed to maintain free space in the specific
On K, 2005-08-31 at 16:50 +0900, Satoshi Nagayasu wrote:
> Simon Riggs wrote:
> >>4. Allow to repair fragmentation in each page.
> >>
> >>Because updates cause fragmentation in the page.
> >>
> >>So we need to keep large continuous free space in each page,
> >>if we want to get more effective on PC
Simon Riggs wrote:
>>4. Allow to repair fragmentation in each page.
>>
>>Because updates cause fragmentation in the page.
>>
>>So we need to keep large continuous free space in each page,
>>if we want to get more effective on PCTFREE feature.
>
>
> ...doesn't VACUUM already do that?
VACUUM gener
On Wed, 2005-08-31 at 08:32 +0900, Satoshi Nagayasu wrote:
> Simon Riggs wrote:
> > The summary was:
> >
> > 1. Have a PCTFREE column added on a table by table basis
>
> I think a good place to keep PCTFREE value is a new column
> in the pg_class, and ALTER TABLE should be able to change this val
Simon Riggs wrote:
> The summary was:
>
> 1. Have a PCTFREE column added on a table by table basis
I think a good place to keep PCTFREE value is a new column
in the pg_class, and ALTER TABLE should be able to change this value.
> 2. Apply PCTFREE for Inserts only
> 3. Allow Updates to use the fu
On Wed, 2005-08-24 at 17:24 -0700, Josh Berkus wrote:
> Satoshi,
>
> > I've created a new patch which can be applied to the current cvs tree.
> >
> > http://dpsql.sourceforge.net/pctfree.cvs.diff
>
> Hmmm ... I don't see where I set the GUC. How am I supposed to vary the
> PCTFREE amount?
>
Satoshi,
> I've created a new patch which can be applied to the current cvs tree.
>
> http://dpsql.sourceforge.net/pctfree.cvs.diff
Hmmm ... I don't see where I set the GUC. How am I supposed to vary the
PCTFREE amount?
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
-
Satoshi Nagayasu wrote:
> Josh Berkus wrote:
>
>>Satoshi, if you can package up a patch on current CVS, I'll throw it at DBT2.
>
> Ok. I'll do it.
I've created a new patch which can be applied to the current cvs tree.
http://dpsql.sourceforge.net/pctfree.cvs.diff
--
NAGAYASU Satoshi <[EMAIL P
Josh Berkus wrote:
> Satoshi, if you can package up a patch on current CVS, I'll throw it at DBT2.
Ok. I'll do it.
--
NAGAYASU Satoshi <[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
On Mon, Aug 22, 2005 at 10:18:25PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > ... But I agree with Satoshi; if there are
> > people who will benefit from this option (which doesn't hurt those who
> > choose not to use it), why not put it in?
>
> Because there's no such
Jim, Satoshi,
> It should be possible to see what the crossover point is in terms of
> benefit using dbt2 and tweaking the transactions that are run, something
> I can do if there's interest. But I agree with Satoshi; if there are
> people who will benefit from this option (which doesn't hurt thos
Jim C. Nasby wrote:
It should be possible to see what the crossover point is in terms of
benefit using dbt2 and tweaking the transactions that are run, something
I can do if there's interest. But I agree with Satoshi; if there are
people who will benefit from this option (which doesn't hurt thos
Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>
>>... But I agree with Satoshi; if there are
>>people who will benefit from this option (which doesn't hurt those who
>>choose not to use it), why not put it in?
>
>
> Because there's no such thing as a free lunch. Every option we s
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> ... But I agree with Satoshi; if there are
> people who will benefit from this option (which doesn't hurt those who
> choose not to use it), why not put it in?
Because there's no such thing as a free lunch. Every option we support
costs us in initial i
On Sun, Aug 21, 2005 at 09:50:10PM -0400, Tom Lane wrote:
> Satoshi Nagayasu <[EMAIL PROTECTED]> writes:
> > I've done a quick hack to implement PCTFREE on PostgreSQL.
> > ...
> > According to my experiments, pgbench score was improved 10% or more
> > with 1024 bytes free space.
>
> I'm not very e
Tom Lane wrote:
> I'm not very enthused about this. Enforcing 12.5% PCTFREE means that
> you pay 12.5% extra I/O costs across the board for INSERT and SELECT
> and then hope you can make it back (plus some more) on UPDATEs.
> pgbench is a completely UPDATE-dominated benchmark and thus it makes
> s
Satoshi Nagayasu <[EMAIL PROTECTED]> writes:
> I've done a quick hack to implement PCTFREE on PostgreSQL.
> ...
> According to my experiments, pgbench score was improved 10% or more
> with 1024 bytes free space.
I'm not very enthused about this. Enforcing 12.5% PCTFREE means that
you pay 12.5% ex
Hi all,
I've done a quick hack to implement PCTFREE on PostgreSQL.
As you know, it's inspired by Oracle's PCTFREE.
http://www.csee.umbc.edu/help/oracle8/server.815/a67772/schema.htm#990
http://www.comp.hkbu.edu.hk/docs/o/oracle10g/server.101/b10743/cncpt031.gif
Pre-allocated space for each bloc
27 matches
Mail list logo
