"Nicolas Barbier" <[EMAIL PROTECTED]> writes:
> 2006/4/3, Tom Lane <[EMAIL PROTECTED]>:
>> AFAICS there are no circumstances, ever, in which update-in-place is
>> "safe". (No transaction can guarantee that it will commit.)
> Updates to row values that did not "escape" the currect transaction
> ye
2006/4/3, Tom Lane <[EMAIL PROTECTED]>:
> "Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> > we're working on a prototype to reduce WAL I/O and index updates in a
> > large percentage of OLTP situations by employing an update-in-place
> > under *safe* conditions.
>
> AFAICS there are no circumstanc
itions. If you have an SMP box, please run some tests.
M
_ Original message _
Subject: Re: [HACKERS] WAL Bypass for indexes
Author: Simon Riggs <[EMAIL PROTECTED]>
Date: 05th April 2006 11:0:34 AM
On Wed, 2006-04-05 at 09:40 -0700, Martin Scholes wrote:
> > I w
On Wed, 2006-04-05 at 09:40 -0700, Martin Scholes wrote:
> > I will run multiple tests and post the actual numbers.
>
> I did run more extensive tests and did not bother writing down the
> numbers, and here's why: the unmodified Pg ran pgbench with a whopping
> average of 6.3% time in IO wait.
>
"Martin Scholes" <[EMAIL PROTECTED]> writes:
> On a related note, we currently have some indexes that are unsafe during
> recovery (GIST and Hash come to mind).
> In the spirit of making Pg "safe at any speed," would it make sense to put
> some code in the recovery section that rebuilds all indexe
Title: Converted from Rich Text
I wrote:
> I will run multiple tests and post the actual numbers.
I did run more extensive tests and did not bother writing down the numbers, and here's why: the unmodified Pg ran pgbench with a whopping average of 6.3% time in IO wait.
If I was abl
Jonah H. Harris wrote:
> As long as it's optional, I guess it's OK to let the administrator
> deal with recovery. Of course, in addition to no-fsync, we'll have
> another *possibly* dangerous option. BTW, I've seen no-fsync used far
> too many times because people think they're hardware is invin
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Ãhel kenal päeval, E, 2006-04-03 kell 09:55, kirjutas Tom Lane:
>> (2) Some of the index code is itself deliberately nondeterministic.
>> I'm thinking in particular of the move-right-or-not choice in
>> _bt_insertonpg() when there are many equal keys, b
Ühel kenal päeval, E, 2006-04-03 kell 09:55, kirjutas Tom Lane:
> (2) Some of the index code is itself deliberately nondeterministic.
> I'm thinking in particular of the move-right-or-not choice in
> _bt_insertonpg() when there are many equal keys, but randomization is
> in general a useful algori
Ühel kenal päeval, E, 2006-04-03 kell 01:48, kirjutas Tom Lane:
> "Martin Scholes" <[EMAIL PROTECTED]> writes:
> > Ok Tom, I stand corrected.
>
> > I downloaded the latest snapshot and both scenarios (normal and WAL bypass =
> > for indexes) produced between 185 and 230 tps on my machine.
>
> > T
On Mon, 2006-04-03 at 09:55 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Thinking about this some more, I ask myself: why is it we log index
> > inserts at all? We log heap inserts, which contain all the information
> > we need to replay all index inserts also, so why bother
Simon Riggs <[EMAIL PROTECTED]> writes:
> Thinking about this some more, I ask myself: why is it we log index
> inserts at all? We log heap inserts, which contain all the information
> we need to replay all index inserts also, so why bother?
(1) We can't run user-defined functions during log repla
t is possible that the improvement was so small compared to the variance that it was hard to see. I will run multiple tests and post the actual numbers.
Cheers,
M
_ Original message _
Subject: Re: [HACKERS] WAL Bypass for indexes
Author: Tom Lane <[EMAIL PROTECTED]>
Dat
On Sun, 2006-04-02 at 20:39 -0700, Martin Scholes wrote:
> The lesson here is that whatever WAL magic has been performed on the
> latest release gives over 100% speedup
That is good news.
> and the speedup is so good that skipping WAL for indexes does
> basically nothing.
I don't agree with th
"Martin Scholes" <[EMAIL PROTECTED]> writes:
> Ok Tom, I stand corrected.
> I downloaded the latest snapshot and both scenarios (normal and WAL bypass =
> for indexes) produced between 185 and 230 tps on my machine.
> The lesson here is that whatever WAL magic has been performed on the latest =
>
On 4/2/06, Martin Scholes <[EMAIL PROTECTED]> wrote:
> The lesson here is that whatever WAL magic has been performed on the latest
> release gives over 100% speedup, and the speedup is so good that skipping
> WAL for indexes does basically nothing.
No need for me to reply to earlier messages :)
-
gives over 100% speedup, and the speedup is so good that skipping WAL for indexes does basically nothing.
Kudos.
Cheers,
M
_ Original message _
Subject: Re: [HACKERS] WAL Bypass for indexes
Author: Tom Lane <[EMAIL PROTECTED]>
Date: 02nd April 2006 5:17:50 PM
&
Martin's proposal at least looks sensible; he just hasn't quite made the
case that it's worth doing. If you're running a system that hardly ever
crashes, you might be willing to accept index rebuilds during crash
recovery, especially for indexes on relatively small, but frequently
updated, tables
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> I guess I can think of a few instances, but none that I would've
> chosen to use it in. IIRC, it's also more likely to increase the cost
> of checkpointing and/or require a good amount of bgwriter tuning.
How so? AFAICS it'd just eliminate WAL outp
> AFAICS there are no circumstances, ever, in which update-in-place is
> "safe". (No transaction can guarantee that it will commit.)
In our case, it is totally safe. I'd certainly like to discuss it
with you sometime at the anniversary.
> Martin's proposal at least looks sensible; he just hasn'
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> we're working on a prototype to reduce WAL I/O and index updates in a
> large percentage of OLTP situations by employing an update-in-place
> under *safe* conditions.
AFAICS there are no circumstances, ever, in which update-in-place is
"safe". (No t
On 4/2/06, Martin Scholes <[EMAIL PROTECTED]> wrote:
> I have long believed that the bottleneck in transaction-oriented systems is
> the writing of the indexes, complete with splits and merges. A single update
> to one field of a heavily-indexed table could cause dozens of index writes
> to cascade
"Martin Scholes" <[EMAIL PROTECTED]> writes:
> I did some informal testing using pgbench on v8.07. First, I ran pgbench =
> normally with 75 users doing 100 transactions, full vacuuming between runs. =
> My machine consistently gave me 92 tps.
> As an experiment, I commented out of the btree ind
Title: Converted from Rich Text
I have followed the discussion from 3 months ago on WAL bypass and wanted to offer some more information.
I have long believed that the bottleneck in transaction-oriented systems is the writing of the indexes, complete with splits and merges. A single u
24 matches
Mail list logo
