On Wed, 16 Jan 2008, Kevin Grittner wrote:
I haven't seen any benchmarks on the list or in our environment
where the separate spindles gave more than a 1% increase in
performance when using a good-quality BBC controller.
Well, even 1% isn't nothing, which is the main point I was making--it
do
Alvaro Herrera wrote:
Heikki Linnakangas escribió:
For more usefulness, we'd need to keep databases more separate from each
other than we do now. Databases would need to have their own transaction
counters, for example.
Hmm, why? Perhaps you are right but I don't see the reason.
If each da
Heikki Linnakangas escribió:
> I don't think it's going to work too well, though, not without major
> changes at least. What would happen when you restore a PITR backup of just
> one database? Would the other databases still be there in the restored
> cluster? What state would they be in? After
On Jan 16, 2008 7:41 PM, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> I don't think it's going to work too well, though, not without major
> changes at least.
Well, I know it's really not doable with the current behaviour of WAL.
I just wanted to point this feature request because we had it a f
>
>
> For more usefulness, we'd need to keep databases more separate from each
> other than we do now. Databases would need to have their own transaction
> counters, for example. Shared relations would obviously need major
> changes for that to work. If we ultimately could separate databases so
> t
Guillaume Smet wrote:
On Jan 16, 2008 6:12 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Tom Lane escribió:
Possibly true, but if that's the underlying hardware then there's no
performance benefit in breaking WAL up at all, no?
Selective PITR shipping.
If it was possible to launch a PITR onl
>>> On Wed, Jan 16, 2008 at 11:40 AM, in message
<[EMAIL PROTECTED]>, Greg Smith
<[EMAIL PROTECTED]> wrote:
> On Wed, 16 Jan 2008, Alvaro Herrera wrote:
>
>> Keep in mind that there are claims that a write-cache-enabled
>> battery-backed RAID controller negates the effect of a separate spindle.
>
On Wed, 16 Jan 2008, Alvaro Herrera wrote:
Keep in mind that there are claims that a write-cache-enabled
battery-backed RAID controller negates the effect of a separate spindle.
"Negates" is a bit strong; there's still some performance advantage on
systems that write a serious amount of data.
On Jan 16, 2008 6:12 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Tom Lane escribió:
> > Possibly true, but if that's the underlying hardware then there's no
> > performance benefit in breaking WAL up at all, no?
>
> Selective PITR shipping.
If it was possible to launch a PITR only on a given d
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Heikki Linnakangas escribió:
>>> Another issue is that reading WAL is inherently not very scalable. There's
>>> only one WAL for the whole cluster, and it needs to be read sequentially,
>>> so it can easily be
Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane escribió:
> >> It would only be useful to have one per spindle-dedicated-to-WAL, so
> >> tying the division to databases doesn't seem like it'd be a good idea.
>
> > Keep in mind that there are claims that a write-cache-e
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane escribió:
>> It would only be useful to have one per spindle-dedicated-to-WAL, so
>> tying the division to databases doesn't seem like it'd be a good idea.
> Keep in mind that there are claims that a write-cache-enabled
> battery-backed RAID c
Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Heikki Linnakangas escribi�:
> >> Another issue is that reading WAL is inherently not very scalable. There's
> >> only one WAL for the whole cluster, and it needs to be read sequentially,
> >> so it can easily become a bottleneck
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas escribió:
>> Another issue is that reading WAL is inherently not very scalable. There's
>> only one WAL for the whole cluster, and it needs to be read sequentially,
>> so it can easily become a bottleneck on large systems.
> I have
>
>
> I haven't been paying close attention to this thread, but there is a
> couple general issues with using the WAL for this kind of things. First
> of all, one extremely cool feature of PostgreSQL is that transaction
> size is not limited by WAL space, unlike on many other DBMSs. I think
> many
Heikki Linnakangas escribió:
> Another issue is that reading WAL is inherently not very scalable. There's
> only one WAL for the whole cluster, and it needs to be read sequentially,
> so it can easily become a bottleneck on large systems.
I have wondered why do we do it this way. Is there a pr
Gokulakannan Somasundaram wrote:
Well, one of the principal arguments for having VACUUM at all is that it
off-loads required maintenance effort from foreground transaction code
paths. I'm not really going to be in favor of solutions that put more
work into the transaction code paths (HOT alread
>
>
> Well, one of the principal arguments for having VACUUM at all is that it
> off-loads required maintenance effort from foreground transaction code
> paths. I'm not really going to be in favor of solutions that put more
> work into the transaction code paths (HOT already did more of that than
One more application of the same is Asynchronous Materialized views. I hope
you agree that the asynchronous materialized views have to get updated only
through WAL. If WAL can be used for that purpose, why can't we multiplex it?
Thanks,
Gokul.
Hi,
Please find my answers inline
>
> Do you have evidence of that contention being so worse, that it
> justifies the additional WAL reading from disk? (Assuming no WAL
> archiving).
On a broader sense, DSM is a bitmap index with some optimization that has
been placed to make the updates more ef
Hi,
Tom Lane wrote:
Well, one of the principal arguments for having VACUUM at all is that it
off-loads required maintenance effort from foreground transaction code
paths.
Off-loading doesn't mean we don't have to do the work, so it's obviously
is a compromise.
AFAICT, having to write some D
Markus Schiltknecht <[EMAIL PROTECTED]> writes:
>> Since Vacuum process is going to
>> have much more information on what has happened in the database,
> Why should that be? IMO, collecting the information at transaction time
> can give you exactly the same information, if not more or better
>
Hi,
Gokulakannan Somasundaram wrote:
I'm also not sure it really buys us anything over having a second
dead-space-map data structure. The WAL is much larger and serves other
purposes which would limit what we can do with it.
Ok. One obvious advantage is that it saves the contention
Sorry Greg , I missed to read this part before.
On Jan 9, 2008 8:40 PM, Gregory Stark <[EMAIL PROTECTED]> wrote:
>
> "Markus Schiltknecht" <[EMAIL PROTECTED]> writes:
>
> > Hi,
> >
> > Gokulakannan Somasundaram wrote:
> >> If we can ask the Vacuum process to scan the WAL log, it can get all
> the
Hi,
Gokulakannan Somasundaram wrote:
because of the contention. Am i missing something
here? While Vacuum is reading the DSM, operations may not be able to
update the bits. We need to put the DSM in shared memory, if all the
processes are going to update it, whereas if Vacuum is going to form
On Jan 10, 2008 3:43 PM, Markus Schiltknecht <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Gokulakannan Somasundaram wrote:
> > But i am just thinking of creating the DSM
> > by reading through the WAL Logs, instead of asking the Inserts, updates
> > and deletes to do the DSM creation.
>
> What's the advan
Hi,
Gokulakannan Somasundaram wrote:
But i am just thinking of creating the DSM
by reading through the WAL Logs, instead of asking the Inserts, updates
and deletes to do the DSM creation.
What's the advantage of that? What's wrong with collecting the
information for DSM at transaction proces
Markus,
I was re-thinking about what you said. I feel, if we read the WAL
through archiver(Where the archiver is switched on), which anyway reads the
entire WAL Log, it might save some CPU cycles off updates, inserts and
deletes.
The question is about reducing I/Os and i have no do
Hi,
Gregory Stark wrote:
That's an interesting thought. I think your caveats are right but with some
more work it might be possible to work it out. For example if a background
process processed the WAL and accumulated an array of possibly-dead tuples to
process in batch. It would wait whenever i
On Wed, 2008-01-09 at 15:10 +, Gregory Stark wrote:
> The goal should be to improve vacuum, then
> adjust the autovacuum_scale_factor as low as we can. As vacuum gets
> cheaper the scale factor can go lower and lower. We shouldn't allow
> the existing autovacuum behaviour to control the way va
"Markus Schiltknecht" <[EMAIL PROTECTED]> writes:
> Hi,
>
> Gokulakannan Somasundaram wrote:
>> If we can ask the Vacuum process to scan the WAL log, it can get all the
>> relevant details on where it needs to go.
That's an interesting thought. I think your caveats are right but with some
more w
> So it's easily possible having more dead tuples, than live ones. In such
> cases, scanning the WAL can easily takes *longer* than scanning the
> table, because the amount of WAL to read would be bigger.
Yes... i made a wrong assumption there.. so the idea is totally
useless.
Thanks,
Goku
Hi,
Gokulakannan Somasundaram wrote:
If we can ask the Vacuum process to scan
the WAL log, it can get all the relevant details on where it needs to
go.
You seem to be assuming that only few tuples have changed between
vacuums, so that WAL could quickly guide the VACUUM processes to the
area
Hi,
May be i am reposting something which has been discussed to end in this
forum. I have made a search in the archives and i couldn't find any
immediately.
With my relatively small experience in Performance Testing and Tuning,
one of the rules of thumb for getting Performance is "Don't do
34 matches
Mail list logo
