Kris Jurka napsal(a):
On Tue, 28 Oct 2008, Zdenek Kotala wrote:
Kris Jurka napsal(a):
Here's a patch that changes everything over to the the new API and
implements the old API by calling the new API.
It seems to me OK. I have only one comment. I prefer to pfree
allocated memory for temp
Alvaro Herrera wrote:
Hannu Krosing wrote:
On Tue, 2008-10-28 at 15:18 -0700, Joshua Drake wrote:
Will there be an helper application for setting up and configuring
changes in replication. or will it all be done using added SQL
commands ?
Well, the interface I work on is all SQL commands :-
It's worth noting that this is the third version of this idea that has
been submitted. Ian Caulfield submitted a patch to add this, and so
did I. Someone should probably look at all three of them and compare.
...Robert
On Mon, Oct 27, 2008 at 1:41 PM, Jeff Davis <[EMAIL PROTECTED]> wrote:
> On
And here's the patch, which based on comments thus far does the following:
- Replaces the use_wal, use_fsm arguments in various places with a
single options argument.
- Creates a BAS_BULKWRITE buffer access strategy.
- Creates a BulkInsertState object so that COPY and CTAS can use
BAS_BULKWRITE an
Suresh <[EMAIL PROTECTED]> writes:
> Why is check_stack_depth function enforced in context of evaluating
> expressions in PostgreSQL ? What sort of recursion we are trying to safeguard
> ?
create function foo(int) returns int as $$
select foo($1) $$ language sql;
select foo(1);
Hello,
Why is check_stack_depth function enforced in context of evaluating expressions
in PostgreSQL ? What sort of recursion we are trying to safeguard ?
thanks,
Suresh
Hannu Krosing wrote:
> On Tue, 2008-10-28 at 15:18 -0700, Joshua Drake wrote:
> > The two obvious problems with the existing MCP architecture is:
> >
> > 1. Single point of failure
>
> For async replication there is always SPoF, at least the master until
> first slave has aquired log is a SPoF,
Heikki,
1. In the code, all the referenced page is extracted from the WAL
records in scope and sorted to schedule and avoid double
posix_fadvise() calls.If full page write is included as the first
WAL record, such page is not prefetched.Although there's still
some risk to call posix_fadvis
Hi,
> I think we would have to maintain two pointers one for the prefetch and one
> for the actual running. But the logic in for recovery is complex enough that
> I'm concerned about changing it enough to do that and whether it can be done
> without uglifying the code quite a bit.
Yes, this is wh
Thanks for a lot of inspiring discussions.
Please note that my proposal includes only a few lines of change to
the recovery code itself. It does not affect buffer management,
order of WAL record applying etc. Only change needed is to invoke
prefetch feature if redo is going to read WAL which h
2008/10/29 Tom Lane <[EMAIL PROTECTED]>:
> Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
>> On Tue, Oct 28, 2008 at 01:50:26PM -0400, Tom Lane wrote:
>>> ... So it might be possible to fix
>>> by attaching some new precedence level to the ROWS token.
>
>> Yes. Bison's default is to shift, whic
On Mon, 2008-10-27 at 16:50 -0400, Chris Browne wrote:
> [EMAIL PROTECTED] (Martin Pihlak) writes:
> > Tons of details have been omitted, but should be enough to start discussion.
> > What do you think, does this sound usable? Suggestions, objections?
>
> Slony-I does some vaguely similar stuff in
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Tue, 2008-10-28 at 17:40 -0400, Bruce Momjian wrote:
>> Gregory Stark wrote:
>> > Simon Riggs <[EMAIL PROTECTED]> writes:
>> >
>> > > I'm happy with the idea of a readahead process. I thought we were
>> > > implementing a BackgroundReader process for o
On Tue, 2008-10-28 at 15:18 -0700, Joshua Drake wrote:
> On Tue, 28 Oct 2008 19:46:42 +0200
> Hannu Krosing <[EMAIL PROTECTED]> wrote:
>
> > > The current topics are:
> > >
> > > * New MCP architecture
> >
> > What's new ?
> >
> > I have some doubts about the current architecture based on
On Tue, 28 Oct 2008 19:46:42 +0200
Hannu Krosing <[EMAIL PROTECTED]> wrote:
> > The current topics are:
> >
> > * New MCP architecture
>
> What's new ?
>
> I have some doubts about the current architecture based on my reading
> of replicator wiki, but would like to learn about the "new"
>
Chris Browne wrote:
> Slony-I does some vaguely similar stuff in its handling of "connection
> paths"; here's the schema:
>
> create table @[EMAIL PROTECTED] (
> pa_server int4,
> pa_client int4,
> pa_conninfo text
On Tue, 2008-10-28 at 17:40 -0400, Bruce Momjian wrote:
> Gregory Stark wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> >
> > > I'm happy with the idea of a readahead process. I thought we were
> > > implementing a BackgroundReader process for other uses. Is that dead
> > > now?
> >
> > You
Simon Riggs <[EMAIL PROTECTED]> writes:
> I'm a little unclear as to what is happening with this.
> We have a bug in CVS HEAD, so clearly doing nothing shouldn't really be
> an option.
Doing nothing until release is certainly not an option ;-). But AFAICS
this is not a showstopper for developmen
Gregory Stark wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>
> > I'm happy with the idea of a readahead process. I thought we were
> > implementing a BackgroundReader process for other uses. Is that dead
> > now?
>
> You and Bruce seem to keep resurrecting that idea. I've never liked it -- I
On Tue, 2008-10-28 at 11:01 -0700, Joshua Drake wrote:
> On Tue, 28 Oct 2008 19:46:42 +0200
> Hannu Krosing <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 2008-10-27 at 13:42 -0700, Joshua Drake wrote:
> > > With the recent open sourcing of Replicator, the team has been
> > > trying to come up with ways
On Tue, 28 Oct 2008, Zdenek Kotala wrote:
Kris Jurka napsal(a):
Here's a patch that changes everything over to the the new API and
implements the old API by calling the new API.
It seems to me OK. I have only one comment. I prefer to pfree allocated
memory for temporary nulls array. I th
ITAGAKI Takahiro wrote:
> It might be possbile to add a queryText field into QueryDesc
> and all of the codes using QueryDesc initialize the field with
> their own query texts, but it requires modifications in many
> different modules and copying query text might be needed.
> I don't want to do it
On Tue, 2008-10-28 at 17:36 -0300, Alvaro Herrera wrote:
> Simon Riggs wrote:
> >
> > On Tue, 2008-10-28 at 15:52 -0400, Tom Lane wrote:
> > > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > > On Tue, 2008-10-28 at 14:43 -0400, Tom Lane wrote:
> > > >> Doing nothing until release is certainly not a
On Tue, 2008-10-28 at 19:46 +0200, Hannu Krosing wrote:
>
> * Is there a mailing list for replicator ?
https://lists.commandprompt.com/mailman/listinfo/replicator-general
Regards,
--
Devrim GÜNDÜZ, RHCE
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
htt
Kris Jurka napsal(a):
On Thu, 23 Oct 2008, Kris Jurka wrote:
The problem with trying to deprecate it is that the vast majority of
the backend is still using the old interfaces, so people looking for
inspiration for their external modules will likely end up using the
old interface. Like Alv
Simon Riggs wrote:
>
> On Tue, 2008-10-28 at 15:52 -0400, Tom Lane wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > On Tue, 2008-10-28 at 14:43 -0400, Tom Lane wrote:
> > >> Doing nothing until release is certainly not an option ;-). But AFAICS
> > >> this is not a showstopper for develop
On Tue, 2008-10-28 at 15:52 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Tue, 2008-10-28 at 14:43 -0400, Tom Lane wrote:
> >> Doing nothing until release is certainly not an option ;-). But AFAICS
> >> this is not a showstopper for development so I was intending to wait
Since we require every process to map the shared memory region to the same
address, we don't need the MAKE_PTR/OFFSET code that was needed when that
was not the case. This patch makes shared memory pointers just like
regular pointers.
http://archives.postgresql.org/pgsql-general/2007-08/msg0
hmm, how could I miss that. but than:
thickbook:src gj$ ls -lahd /Users/gj/Projects/postgres-head/pgsql/src/
test/regress/results/
drwxr-xr-x 119 gj staff 4,0K 28 paź 19:14 /Users/gj/Projects/
postgres-head/pgsql/src/test/regress/results/
thickbook:src gj$ touch /Users/gj/Projects/postgre
The attached patch tries to implement regexp support in the usermaps
(pg_ident.conf).
The use-case will be to do things like realm-based matches in
kerberos/GSSAPI authentication (will require some further hacks on that
one to expose the realm name). For example you could have:
krb /^(.*)@myr
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Tue, 2008-10-28 at 14:43 -0400, Tom Lane wrote:
>> Doing nothing until release is certainly not an option ;-). But AFAICS
>> this is not a showstopper for development so I was intending to wait
>> until commitfest starts before doing anything with it.
Grzegorz Jaskiewicz wrote:
I won't send the full logs here, if someone's interested in it - here's
tar.bz2 version:
http://zlew.org/pg_regress.tar.bz2
This seems to be the root cause:
+ ERROR: could not open file
"/Users/gj/Projects/postgres-head/pgsql/src/test/regress/results/onek.data" f
I won't send the full logs here, if someone's interested in it -
here's tar.bz2 version:
http://zlew.org/pg_regress.tar.bz2
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, 2008-10-28 at 14:43 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I'm a little unclear as to what is happening with this.
>
> > We have a bug in CVS HEAD, so clearly doing nothing shouldn't really be
> > an option.
>
> Doing nothing until release is certainly not a
Howdy!
It was suggested to me that this proposed feature is interesting
enough to be floated around for discussion.
Don't get your hopes up, because the request is extremely simple:
It could be useful to have a command that returns the table definition
(like pg_dump -st) from within the que
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> On Tue, Oct 28, 2008 at 01:50:26PM -0400, Tom Lane wrote:
>> ... So it might be possible to fix
>> by attaching some new precedence level to the ROWS token.
> Yes. Bison's default is to shift, which means that if you do nothing it
> will treat R
On Tue, 2008-10-28 at 00:35 +, Simon Riggs wrote:
> Comments please.
I'm a little unclear as to what is happening with this.
We have a bug in CVS HEAD, so clearly doing nothing shouldn't really be
an option. It was my patch with the bug, so clearly my responsibility.
After some prototypes,
On Tue, Oct 28, 2008 at 01:50:26PM -0400, Tom Lane wrote:
> > Given that the only problematic case is if expr_list ends with a
> > postfix operator, wouldn't it be sufficient to simply decree that in
> > that case you need parentheses? Seems a lot less painful than adding
> > two reserved words.
>
On Tue, 2008-10-28 at 13:58 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Mon, 2008-10-27 at 14:03 +0200, Heikki Linnakangas wrote:
> >> Lazy VACUUM only needs to visit pages that are '0' in the visibility
> >> map. This allows partial vacuums, where we only need to scan
On Tue, 28 Oct 2008 19:46:42 +0200
Hannu Krosing <[EMAIL PROTECTED]> wrote:
> On Mon, 2008-10-27 at 13:42 -0700, Joshua Drake wrote:
> > With the recent open sourcing of Replicator, the team has been
> > trying to come up with ways to ensure an open development process.
> > In that light we have d
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Yes, but there's a problem with recently inserted tuples:
> 1. A query begins in the slave, taking a snapshot with xmax = 100. So
> the effects of anything more recent should not be seen.
> 2. Transaction 100 inserts a tuple in the master, and comm
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Mon, 2008-10-27 at 14:03 +0200, Heikki Linnakangas wrote:
>> Lazy VACUUM only needs to visit pages that are '0' in the visibility
>> map. This allows partial vacuums, where we only need to scan those parts
>> of the table that need vacuuming, plus all
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> On Tue, Oct 28, 2008 at 12:38:09PM -0400, Tom Lane wrote:
>> Right offhand, I don't see any alternative but to make both ROWS and
>> RANGE reserved. It's pretty annoying since that might break existing
>> applications that have been using these
On Mon, 2008-10-27 at 13:42 -0700, Joshua Drake wrote:
> With the recent open sourcing of Replicator, the team has been trying
> to come up with ways to ensure an open development process. In that
> light we have decided to have our first release 1.9 meeting on
> Freenode. All people interested in
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> As far as the ugliness in XLogRecordPageWithFreeSpace goes: couldn't you
>> just call XLogReadBufferWithFork with init = true, and then initialize
>> the page if PageIsNew?
> With init=true, we don't even try to read the page from
On Tue, Oct 28, 2008 at 12:38:09PM -0400, Tom Lane wrote:
> "Hitoshi Harada" <[EMAIL PROTECTED]> writes:
> > In window specifications, we have
>
> > OVER (ORDER BY expr_list [(ROWS|RANGE) ... ])
>
> > and currently "ROWS" is not reserved so bison is confused with cases
> > of "ROWS" included in e
On Tue, 2008-10-28 at 19:02 +0200, Heikki Linnakangas wrote:
> Yes, but there's a problem with recently inserted tuples:
>
> 1. A query begins in the slave, taking a snapshot with xmax = 100. So
> the effects of anything more recent should not be seen.
> 2. Transaction 100 inserts a tuple in th
2008/10/29 Tom Lane <[EMAIL PROTECTED]>:
> "Hitoshi Harada" <[EMAIL PROTECTED]> writes:
>> Can "ROWS" be reserved_keyword?
>
>> In window specifications, we have
>
>> OVER (ORDER BY expr_list [(ROWS|RANGE) ... ])
>
>> and currently "ROWS" is not reserved so bison is confused with cases
>> of "ROWS"
Tom Lane wrote:
As far as the ugliness in XLogRecordPageWithFreeSpace goes: couldn't you
just call XLogReadBufferWithFork with init = true, and then initialize
the page if PageIsNew?
With init=true, we don't even try to read the page from the disk (since
8.3), so all FSM pages accessed during
On Mon, 2008-10-27 at 14:03 +0200, Heikki Linnakangas wrote:
> Lazy VACUUM only needs to visit pages that are '0' in the visibility
> map. This allows partial vacuums, where we only need to scan those parts
> of the table that need vacuuming, plus all indexes.
Just realised that this means we
Simon Riggs wrote:
On Tue, 2008-10-28 at 14:57 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Mon, 2008-10-27 at 14:03 +0200, Heikki Linnakangas wrote:
One option would be to just ignore that problem for now, and not
WAL-log.
Probably worth skipping for now, since it will cause patch
On Tue, 2008-10-28 at 12:16 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Or possibly an XLogInsertDeferred() which just queues up some work so
> > the next time we call XLogInsert() it will insert the deferred work as
> > well as the main work all in one lock cycle. It woul
"Hitoshi Harada" <[EMAIL PROTECTED]> writes:
> Can "ROWS" be reserved_keyword?
> In window specifications, we have
> OVER (ORDER BY expr_list [(ROWS|RANGE) ... ])
> and currently "ROWS" is not reserved so bison is confused with cases
> of "ROWS" included in expr_list and in FRAME clause. Because
2008/10/28 Tom Lane <[EMAIL PROTECTED]>:
> "Hitoshi Harada" <[EMAIL PROTECTED]> writes:
>> OK, I'll try to remove it. I'm not used to bison so my first task is
>> to find where the conflict is...
>
> Use bison -v to get details of where the conflict is. I find that
> the most common way to fix thi
Simon Riggs <[EMAIL PROTECTED]> writes:
> Or possibly an XLogInsertDeferred() which just queues up some work so
> the next time we call XLogInsert() it will insert the deferred work as
> well as the main work all in one lock cycle. It would only be usable for
> low priority info like FSM stuff that
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Tue, 2008-10-28 at 12:34 +, Gregory Stark wrote:
>> Simon Riggs <[EMAIL PROTECTED]> writes:
>>
>> I've never liked it -- I
>> always hated that in Oracle and thought it was a terrible kludge.
>
> But now... If you have a better way, great, but that
Simon Riggs wrote:
On Tue, 2008-10-28 at 16:22 +0200, Heikki Linnakangas wrote:
Arbitrarily, if after a
heap insert/update there's less than 20% of free space on the page,
the FSM is updated. Compared to updating it every time, that saves a
lot of overhead, while doing a pretty good job at mar
On Tue, 2008-10-28 at 16:22 +0200, Heikki Linnakangas wrote:
> Arbitrarily, if after a
> heap insert/update there's less than 20% of free space on the page,
> the FSM is updated. Compared to updating it every time, that saves a
> lot of overhead, while doing a pretty good job at marking full pag
On Tue, 2008-10-28 at 12:34 +, Gregory Stark wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>
> > I'm happy with the idea of a readahead process. I thought we were
> > implementing a BackgroundReader process for other uses. Is that dead
> > now?
>
> You and Bruce seem to keep resurrecting
This file is for add to pgsql-docs, is the translation of the FAQ_solaris.
I have new things to add, specially for Open Solaris plattaform specifications.
I can write a new FAQ or just concatenate to this the other features
of OSolaris?
Reggards,
--
Emanuel Calvo Franco
Syscope Postgr
On Tue, 2008-10-28 at 15:35 +, Simon Riggs wrote:
> I wonder if there is merit in having an XLogInsertMulti() which inserts
> multiple records in a batch as a way of reducing WALInsertLock traffic.
> It might be possible to piggyback FSM records onto the main heap
> changes.
Or possibly an X
2008/10/28 Dimitri Fontaine <[EMAIL PROTECTED]>:
> Hi,
>
> In the python language, functions that lazily return collections are called
> generators and use the yield keyword instead of return.
> http://www.python.org/doc/2.5.2/tut/node11.html#SECTION0011100
>
> Maybe having such a c
Hi,
In the python language, functions that lazily return collections are called
generators and use the yield keyword instead of return.
http://www.python.org/doc/2.5.2/tut/node11.html#SECTION0011100
Maybe having such a concept in PostgreSQL would allow the user to choose
between
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> So we should try to update the FSM during recovery as well. It doesn't
> need to be very accurate, as the FSM information isn't accurate anyway,
> but we should try to avoid the worst case scenarios.
Agreed.
> One issue with this patch is that it
Gregory Stark wrote:
Simon Riggs <[EMAIL PROTECTED]> writes:
And are people running raid arrays not likely to be
running modern OSes anyways?
No and those that are can upgrade.
Joshua D. Drake
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your s
>> I always thought we considered that a bug though. It sure would be nice if we
>> could generate results as needed instead of having to generate them in
>> advance
>> and store all of them.
> I suppose, but short of a fundamental rethink of how PL functions work
> that's not going to happen. Th
On Tue, 2008-10-28 at 14:57 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Mon, 2008-10-27 at 14:03 +0200, Heikki Linnakangas wrote:
> >> One option would be to just ignore that problem for now, and not
> >> WAL-log.
> >
> > Probably worth skipping for now, since it will cause patc
The one remaining issue I'd like to address in the new FSM
implementation is the fact that the FSM is currently not updated at all
in WAL recovery. The old FSM wasn't updated on WAL recovery either, and
was in fact completely thrown away if the system wasn't shut down
cleanly. The difference is
I wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>> On Sun, 2008-10-26 at 21:49 -0400, Tom Lane wrote:
>>> ... effort into tuplestore optimization. (I note that the current
>>> tuplestore code writes 24 bytes per row for this example, which is a
>>> shade on the high side for only 4 bytes payloa
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
To modify a page:
If PD_ALL_VISIBLE flag is set, the bit in the visibility map is cleared
first. The heap page is kept pinned, but not locked, while the
visibility map is updated. We want to avoid holding a lock across I/O,
even t
Tom Lane wrote:
The harder part is propagating the bit to the visibility map, but I
gather you intend to only allow VACUUM to do that?
Yep.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
On Tue, Oct 28, 2008 at 09:28:38AM -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Sun, 2008-10-26 at 21:49 -0400, Tom Lane wrote:
> >> So I'm concluding that we can easily afford to switch to
> >> tuplestore-always operation, especially if we are willing to put any
> >> eff
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Sun, 2008-10-26 at 21:49 -0400, Tom Lane wrote:
>> So I'm concluding that we can easily afford to switch to
>> tuplestore-always operation, especially if we are willing to put any
>> effort into tuplestore optimization. (I note that the current
>> tuple
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> I suspect it doesn't help you as much as you think. It's always been
>> the case that SRFs in FROM-items are fed through a tuplestore, and so
>> are plpgsql SRF results.
> I always thought we considered that a b
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> ... I'm not sure if it would
> be safe to set the PD_ALL_VISIBLE_FLAG while holding just a shared lock,
> though. If it is, then we could do just that.
Seems like it must be safe. If you have shared lock on a page then no
one else could be modify
Simon Riggs wrote:
On Mon, 2008-10-27 at 14:03 +0200, Heikki Linnakangas wrote:
One option would be to just ignore that problem for now, and not
WAL-log.
Probably worth skipping for now, since it will cause patch conflicts if
you do. Are there any other interactions with Hot Standby?
But it
"Hitoshi Harada" <[EMAIL PROTECTED]> writes:
> OK, I'll try to remove it. I'm not used to bison so my first task is
> to find where the conflict is...
Use bison -v to get details of where the conflict is. I find that
the most common way to fix things is to postpone where the parser
has to make a
On Tue, 2008-10-28 at 14:28 +0200, Heikki Linnakangas wrote:
> Hannu Krosing wrote:
> > On Tue, 2008-10-28 at 10:10 +, Simon Riggs wrote:
> >> On Tue, 2008-10-28 at 11:45 +0200, Hannu Krosing wrote:
> >>> On Tue, 2008-10-28 at 08:49 +, Simon Riggs wrote:
> Looking at a VACUUM's WAL rec
Gregory Stark wrote:
Simon Riggs <[EMAIL PROTECTED]> writes:
I'm happy with the idea of a readahead process. I thought we were
implementing a BackgroundReader process for other uses. Is that dead
now?
You and Bruce seem to keep resurrecting that idea. I've never liked it -- I
always hated tha
Simon Riggs <[EMAIL PROTECTED]> writes:
> Looking at a VACUUM's WAL records makes me think twice about the way we
> issue a VACUUM.
> 1. First we scan the heap, issuing a HEAP2 clean record for every block
> that needs cleaning.
> 2. Then we scan the index, issuing WAL records as appropriate.
>
Simon Riggs <[EMAIL PROTECTED]> writes:
> I think what I am suggesting is two heap passes, but writing WAL and
> dirtying blocks on only one of the passes.
I think you've all forgotten about hint-bit setting. The assumption is
that the first VACUUM pass is going to update a lot of hint bits and w
Simon Riggs <[EMAIL PROTECTED]> writes:
> I'm happy with the idea of a readahead process. I thought we were
> implementing a BackgroundReader process for other uses. Is that dead
> now?
You and Bruce seem to keep resurrecting that idea. I've never liked it -- I
always hated that in Oracle and tho
2008/10/28 Tom Lane <[EMAIL PROTECTED]>:
> "Hitoshi Harada" <[EMAIL PROTECTED]> writes:
>> 2008/10/28 ITAGAKI Takahiro <[EMAIL PROTECTED]>:
>>> I tested the patch on mingw (Windows) and
>>> got the following warning and error:
>>>
>>> A. gram.y: conflicts: 3 shift/reduce
>>> B. include/nodes/planno
Hannu Krosing wrote:
On Tue, 2008-10-28 at 10:10 +, Simon Riggs wrote:
On Tue, 2008-10-28 at 11:45 +0200, Hannu Krosing wrote:
On Tue, 2008-10-28 at 08:49 +, Simon Riggs wrote:
Looking at a VACUUM's WAL records makes me think twice about the way we
issue a VACUUM.
1. First we scan the
"Hitoshi Harada" <[EMAIL PROTECTED]> writes:
> 2008/10/28 ITAGAKI Takahiro <[EMAIL PROTECTED]>:
>> I tested the patch on mingw (Windows) and
>> got the following warning and error:
>>
>> A. gram.y: conflicts: 3 shift/reduce
>> B. include/nodes/plannodes.h:650: error: syntax error before "uint"
>>
Gregory Stark wrote:
"Koichi Suzuki" <[EMAIL PROTECTED]> writes:
This is my first proposal of PITR performance improvement for
PostgreSQL 8.4 development. This proposal includes readahead
mechanism of data pages which will be read by redo() routines in the
recovery. This is especially effec
On Tue, 2008-10-28 at 10:10 +, Simon Riggs wrote:
> On Tue, 2008-10-28 at 11:45 +0200, Hannu Krosing wrote:
> > On Tue, 2008-10-28 at 08:49 +, Simon Riggs wrote:
> > > Looking at a VACUUM's WAL records makes me think twice about the way we
> > > issue a VACUUM.
> > >
> > > 1. First we scan
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Tue, 2008-10-28 at 10:59 +, Gregory Stark wrote:
>> To do that he proposed we do:
>>
>> 1. scan heap doing two things: a) remove any marked tuples if they were
>> marked
>>by a previous vacuum which committed and b) prune and mark any tuples w
On Tue, 2008-10-28 at 16:33 +0900, Koichi Suzuki wrote:
> This is my first proposal of PITR performance improvement for
> PostgreSQL 8.4 development. This proposal includes readahead
> mechanism of data pages which will be read by redo() routines in the
> recovery. This is especially effectiv
On Mon, 2008-10-27 at 14:03 +0200, Heikki Linnakangas wrote:
> One option would be to just ignore that problem for now, and not
> WAL-log.
Probably worth skipping for now, since it will cause patch conflicts if
you do. Are there any other interactions with Hot Standby?
But it seems like we can
On Tue, 2008-10-28 at 10:59 +, Gregory Stark wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>
> > I don't see a reason why we would issue 2 WAL records per block for a
> > VACUUM, nor why we would prune and remove in two steps, dirtying the
> > block each time. Seems like we could write app
Simon Riggs <[EMAIL PROTECTED]> writes:
> I don't see a reason why we would issue 2 WAL records per block for a
> VACUUM, nor why we would prune and remove in two steps, dirtying the
> block each time. Seems like we could write approximately half the amount
> of data that we do.
>
> Surely we can
"Koichi Suzuki" <[EMAIL PROTECTED]> writes:
> This is my first proposal of PITR performance improvement for
> PostgreSQL 8.4 development. This proposal includes readahead
> mechanism of data pages which will be read by redo() routines in the
> recovery. This is especially effective in the reco
On Sun, 2008-10-26 at 21:49 -0400, Tom Lane wrote:
> So I'm concluding that we can easily afford to switch to
> tuplestore-always operation, especially if we are willing to put any
> effort into tuplestore optimization. (I note that the current
> tuplestore code writes 24 bytes per row for this e
Tom Lane <[EMAIL PROTECTED]> writes:
> "Robert Haas" <[EMAIL PROTECTED]> writes:
>> I'm pretty excited by that example. LIMIT/OFFSET is really useful as
>> a way of paginating query results for display on a web page (show
>> results 1-100, 101-200, etc), and I use it on potentially expensive
>>
On Tue, 2008-10-28 at 11:45 +0200, Hannu Krosing wrote:
> On Tue, 2008-10-28 at 08:49 +, Simon Riggs wrote:
> > Looking at a VACUUM's WAL records makes me think twice about the way we
> > issue a VACUUM.
> >
> > 1. First we scan the heap, issuing a HEAP2 clean record for every block
> > that
On Tue, 2008-10-28 at 08:49 +, Simon Riggs wrote:
> Looking at a VACUUM's WAL records makes me think twice about the way we
> issue a VACUUM.
>
> 1. First we scan the heap, issuing a HEAP2 clean record for every block
> that needs cleaning.
IIRC the first heap pass just collects info and does
2008/10/28 ITAGAKI Takahiro <[EMAIL PROTECTED]>:
>
> "Hitoshi Harada" <[EMAIL PROTECTED]> wrote:
>
>> And I fixed this problem, confirming with/without debug/cassert/gcc
>> -O and push it to git. If you want delta patch, please see
>> http://git.postgresql.org/?p=~davidfetter/window_functions/.git
Looking at a VACUUM's WAL records makes me think twice about the way we
issue a VACUUM.
1. First we scan the heap, issuing a HEAP2 clean record for every block
that needs cleaning.
2. Then we scan the index, issuing WAL records as appropriate.
3. Then we rescan the heap, issuing a HEAP2 clean re
"Hitoshi Harada" <[EMAIL PROTECTED]> wrote:
> And I fixed this problem, confirming with/without debug/cassert/gcc
> -O and push it to git. If you want delta patch, please see
> http://git.postgresql.org/?p=~davidfetter/window_functions/.git;a=commitdiff;h=fbf19bfd0c8d2ac083b775f4cc724ec66e74fa8f
1 - 100 of 102 matches
Mail list logo
