On 2014-10-30 18:06:02 -0500, Jim Nasby wrote:
> On 10/30/14, 2:13 PM, Heikki Linnakangas wrote:
> >On 10/30/2014 08:56 PM, Andres Freund wrote:
> >>I actually think we should *always* use the new code and not
> >>add a separate wal_level=minimal branch. Maintaining this twice just
> >>isn't worth
On 10/30/14, 2:13 PM, Heikki Linnakangas wrote:
On 10/30/2014 08:56 PM, Andres Freund wrote:
I actually think we should *always* use the new code and not
add a separate wal_level=minimal branch. Maintaining this twice just
isn't worth the effort. minimal is used *far* less these days.
I wouldn
On 10/30/2014 08:56 PM, Andres Freund wrote:
I actually think we should *always* use the new code and not
add a separate wal_level=minimal branch. Maintaining this twice just
isn't worth the effort. minimal is used *far* less these days.
I wouldn't go that far. Doing the wal_level=minimal optim
On 10/30/2014 08:51 PM, Robert Haas wrote:
On Wed, Oct 29, 2014 at 2:36 PM, Tomas Vondra wrote:
I would tend not to worry too much about this case. I'm skeptical
that there are a lot of people using large template databases. But
if there are, or if some particular one of those people hits this
On 2014-10-30 14:51:54 -0400, Robert Haas wrote:
> On Wed, Oct 29, 2014 at 2:36 PM, Tomas Vondra wrote:
> >> I would tend not to worry too much about this case. I'm skeptical
> >> that there are a lot of people using large template databases. But
> >> if there are, or if some particular one of tho
On Wed, Oct 29, 2014 at 2:36 PM, Tomas Vondra wrote:
>> I would tend not to worry too much about this case. I'm skeptical
>> that there are a lot of people using large template databases. But
>> if there are, or if some particular one of those people hits this
>> problem, then they can raise check
On 29.10.2014 18:31, Robert Haas wrote:
> On Mon, Oct 27, 2014 at 8:01 PM, Tomas Vondra wrote:
>> (3) write-heavy workloads / large template database
>>
>> Current approach wins, for two reasons: (a) for large databases the
>> WAL-logging overhead may generate much more I/O than a checkpoi
On Mon, Oct 27, 2014 at 8:01 PM, Tomas Vondra wrote:
> (3) write-heavy workloads / large template database
>
> Current approach wins, for two reasons: (a) for large databases the
> WAL-logging overhead may generate much more I/O than a checkpoint,
> and (b) it may generate so many WAL
On 10/28/2014 02:56 AM, David G Johnston wrote:
Tom Lane-2 wrote
So maybe we shouldn't cling to the WAL-logging approach too much. Maybe
Heikki's idea from to abandon the full checkpoint and instead assume
that once the transaction commits, all the files were fsynced OK. Of
couse, this will do n
Tom Lane-2 wrote
> Tomas Vondra <
> tv@
> > writes:
>> So maybe we shouldn't cling to the WAL-logging approach too much. Maybe
>> Heikki's idea from to abandon the full checkpoint and instead assume
>> that once the transaction commits, all the files were fsynced OK. Of
>> couse, this will do not
Tomas Vondra wrote
> I mean, when we use database A as a template, why do we need to checkpoint
> B, C, D and F too? (Apologies if this is somehow obvious, I'm way out of
> my comfort zone in this part of the code.)
IIUC you have to checkpoint the whole cluster because it is not possible to
do che
Tomas Vondra writes:
> So maybe we shouldn't cling to the WAL-logging approach too much. Maybe
> Heikki's idea from to abandon the full checkpoint and instead assume
> that once the transaction commits, all the files were fsynced OK. Of
> couse, this will do nothing about the replay hazards.
Well
On 28.10.2014 00:06, Andrew Dunstan wrote:
>
> On 10/27/2014 07:01 PM, Andres Freund wrote:
>> On 2014-10-27 18:57:27 -0400, Andrew Dunstan wrote:
>>> On 10/27/2014 05:58 PM, Tomas Vondra wrote:
On 27.10.2014 17:24, Heikki Linnakangas wrote:
I'm also thinking that for wal_level=archive a
Andres Freund writes:
> On 2014-10-27 18:57:27 -0400, Andrew Dunstan wrote:
>> Notwithstanding what the docs say, I have seen CREATE DATABASE used plenty
>> of times, and quite effectively, to clone databases. I don't think making it
>> do twice the IO in the general case is going to go down well.
On 10/27/2014 07:01 PM, Andres Freund wrote:
On 2014-10-27 18:57:27 -0400, Andrew Dunstan wrote:
On 10/27/2014 05:58 PM, Tomas Vondra wrote:
On 27.10.2014 17:24, Heikki Linnakangas wrote:
I'm also thinking that for wal_level=archive and large databases, this
won't really eliminate the checkpoi
On 2014-10-27 18:57:27 -0400, Andrew Dunstan wrote:
>
> On 10/27/2014 05:58 PM, Tomas Vondra wrote:
> >On 27.10.2014 17:24, Heikki Linnakangas wrote:
> >I'm also thinking that for wal_level=archive and large databases, this
> >won't really eliminate the checkpoint as it will likely generate enough
On 10/27/2014 05:58 PM, Tomas Vondra wrote:
On 27.10.2014 17:24, Heikki Linnakangas wrote:
On 10/27/2014 03:46 PM, Tom Lane wrote:
Heikki Linnakangas writes:
On 10/27/2014 03:21 PM, Tomas Vondra wrote:
Thinking about this a bit more, do we really need a full checkpoint?
That
is a checkpoint
Tomas Vondra writes:
> That being said, our CREATE DATABASE docs currently say this
> Although it is possible to copy a database other than template1 by
> specifying its name as the template, this is not (yet) intended as
> a general-purpose "COPY DATABASE" facility. The principal
>
On 27.10.2014 17:24, Heikki Linnakangas wrote:
> On 10/27/2014 03:46 PM, Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> On 10/27/2014 03:21 PM, Tomas Vondra wrote:
Thinking about this a bit more, do we really need a full checkpoint?
That
is a checkpoint of all the databases in th
On 10/27/2014 03:46 PM, Tom Lane wrote:
Heikki Linnakangas writes:
On 10/27/2014 03:21 PM, Tomas Vondra wrote:
Thinking about this a bit more, do we really need a full checkpoint? That
is a checkpoint of all the databases in the cluster? Why checkpointing the
source database is not enough?
On 2014-10-27 09:46:41 -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 10/27/2014 03:21 PM, Tomas Vondra wrote:
> >> Thinking about this a bit more, do we really need a full checkpoint? That
> >> is a checkpoint of all the databases in the cluster? Why checkpointing the
> >> source data
Heikki Linnakangas writes:
> On 10/27/2014 03:21 PM, Tomas Vondra wrote:
>> Thinking about this a bit more, do we really need a full checkpoint? That
>> is a checkpoint of all the databases in the cluster? Why checkpointing the
>> source database is not enough?
> A full checkpoint ensures that yo
On 10/27/2014 03:21 PM, Tomas Vondra wrote:
Dne 27 Říjen 2014, 10:47, Heikki Linnakangas napsal(a):
On 10/26/2014 11:47 PM, Tomas Vondra wrote:
After eyeballing the code for an hour or two, I think CREATE DATABASE
should be fine with performing only a 'partial checkpoint' on the
template databa
Dne 27 Říjen 2014, 10:47, Heikki Linnakangas napsal(a):
> On 10/26/2014 11:47 PM, Tomas Vondra wrote:
>> After eyeballing the code for an hour or two, I think CREATE DATABASE
>> should be fine with performing only a 'partial checkpoint' on the
>> template database - calling FlushDatabaseBuffers and
Dne 27 Říjen 2014, 13:50, Atri Sharma napsal(a):
>>
>>
>>
>> IMHO writing all the data into a WAL would be the cleanest solution.
>>
>> Also, what is a small database? I don't think a static value will work,
>> because the sweet spot between the current approach (forcing two
>> checkpoints) and wri
>
>
>
> IMHO writing all the data into a WAL would be the cleanest solution.
>
> Also, what is a small database? I don't think a static value will work,
> because the sweet spot between the current approach (forcing two
> checkpoints) and writing everything in WAL depends on the amount of dirty
> b
Dne 27 Říjen 2014, 10:47, Heikki Linnakangas napsal(a):
> On 10/26/2014 11:47 PM, Tomas Vondra wrote:
>> After eyeballing the code for an hour or two, I think CREATE DATABASE
>> should be fine with performing only a 'partial checkpoint' on the
>> template database - calling FlushDatabaseBuffers and
On Mon, Oct 27, 2014 at 4:44 PM, Heikki Linnakangas wrote:
> On 10/27/2014 01:06 PM, Atri Sharma wrote:
>
>>
>>>
>>>
To solve #1, we could redesign CREATE DATABASE so that replaying the
>>> DBASE_CREATE record doesn't zap the old directory, and also doesn't copy
>>> any files. We could inst
On 10/27/2014 01:06 PM, Atri Sharma wrote:
To solve #1, we could redesign CREATE DATABASE so that replaying the
DBASE_CREATE record doesn't zap the old directory, and also doesn't copy
any files. We could instead just assume that if the transaction commits,
all the files have been copied and
>
>
>>
> To solve #1, we could redesign CREATE DATABASE so that replaying the
> DBASE_CREATE record doesn't zap the old directory, and also doesn't copy
> any files. We could instead just assume that if the transaction commits,
> all the files have been copied and fsync'd already, like we assume th
On 10/26/2014 11:47 PM, Tomas Vondra wrote:
After eyeballing the code for an hour or two, I think CREATE DATABASE
should be fine with performing only a 'partial checkpoint' on the
template database - calling FlushDatabaseBuffers and processing unlink
requests, as suggested by the comment in creat
Hi all,
currently, CREATE DATABASE forces an immediate checkpoint (actually, it
forces two, but the time interval is usually rather small). For
traditional deployments this is not a big deal, because creating a
database is a rare event, and may be planned to off-peak times.
However for shared (cl
32 matches
Mail list logo
