Hi Heikki,
On Mon, Feb 11, 2013 at 7:28 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 11.02.2013 08:44, Jeevan Chalke wrote:
Hi,
Any review comments on this ?
Sorry for the delay.
I did some minor cleanup on this. I added code to pg_resetxlog and
pg_controldata to reset /
On 11.02.2013 08:44, Jeevan Chalke wrote:
Hi,
Any review comments on this ?
Sorry for the delay.
I did some minor cleanup on this. I added code to pg_resetxlog and
pg_controldata to reset / display the current unlogged LSN value. I
moved the static counter, for temporary relations, back to
Hi,
Any review comments on this ?
On Tue, Jan 29, 2013 at 6:03 PM, Jeevan Chalke
jeevan.cha...@enterprisedb.com wrote:
Hi Heikki,
On Mon, Jan 28, 2013 at 2:34 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 23.01.2013 17:30, Robert Haas wrote:
On Wed, Jan 23, 2013 at 4:04
Hi Heikki,
On Mon, Jan 28, 2013 at 2:34 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 23.01.2013 17:30, Robert Haas wrote:
On Wed, Jan 23, 2013 at 4:04 AM, Jeevan Chalke
jeevan.chalke@enterprisedb.**com jeevan.cha...@enterprisedb.com
wrote:
I guess my earlier patch, which
On 23.01.2013 17:30, Robert Haas wrote:
On Wed, Jan 23, 2013 at 4:04 AM, Jeevan Chalke
jeevan.cha...@enterprisedb.com wrote:
I guess my earlier patch, which was directly incrementing
ControlFile-unloggedLSN counter was the concern as it will take
ControlFileLock several times.
In this version
On Mon, Jan 28, 2013 at 4:04 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Do we need to do anything to unloggedLSN in pg_resetxlog?
Does the server go into recovery after pg_resetxlog? If so, no. If
not, probably, but I have no idea what. There's no safe value in
that case; what we
On Wed, Jan 16, 2013 at 3:24 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 15, 2013 at 4:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I think that might be acceptable from a performance point of view -
after all, if the index is unlogged,
On Wed, Jan 23, 2013 at 4:04 AM, Jeevan Chalke
jeevan.cha...@enterprisedb.com wrote:
Yes.
I guess my earlier patch, which was directly incrementing
ControlFile-unloggedLSN counter was the concern as it will take
ControlFileLock several times.
In this version of patch I did what Robert has
On 15.01.2013 08:54, Jeevan Chalke wrote:
For (2), I have added a new function called, GetXLogRecPtrForUnloogedRel()
which returns a fake LSN for GiST indexes. However, I have removed
GetXLogRecPtrForTemp() function and added its functionality inside this new
function itself to avoid complexity.
On Tue, Jan 15, 2013 at 1:10 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 15.01.2013 08:54, Jeevan Chalke wrote:
For (2), I have added a new function called, GetXLogRecPtrForUnloogedRel()
which returns a fake LSN for GiST indexes. However, I have removed
GetXLogRecPtrForTemp()
On 15.01.2013 20:33, Robert Haas wrote:
On Tue, Jan 15, 2013 at 1:10 PM, Heikki Linnakangas
Could we stash the counter e.g. in the root page of the index?
That would require maintaining a counter per table rather than a
single global counter, which would be bad because then we'd need to
store
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 15, 2013 at 1:10 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Could we stash the counter e.g. in the root page of the index?
That would require maintaining a counter per table rather than a
single global counter, which would be
On Tue, Jan 15, 2013 at 1:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 15, 2013 at 1:10 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Could we stash the counter e.g. in the root page of the index?
That would require maintaining a
On 15.01.2013 20:48, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
On Tue, Jan 15, 2013 at 1:10 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Could we stash the counter e.g. in the root page of the index?
That would require maintaining a counter per table rather than a
On 2013-01-15 20:58:00 +0200, Heikki Linnakangas wrote:
On 15.01.2013 20:48, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
On Tue, Jan 15, 2013 at 1:10 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Could we stash the counter e.g. in the root page of the index?
That
On Tue, Jan 15, 2013 at 1:58 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I think what Heikki had in mind was that the copy in the index would be
the authoritative one, not some image in shared memory. This'd imply
dirtying the root page on every insert, as well as increased
Robert Haas robertmh...@gmail.com writes:
I think that might be acceptable from a performance point of view -
after all, if the index is unlogged, you're saving the cost of WAL -
but I guess I still prefer a generic solution to this problem (a
generalization of GetXLogRecPtrForTemp) rather
On Tue, Jan 15, 2013 at 4:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I think that might be acceptable from a performance point of view -
after all, if the index is unlogged, you're saving the cost of WAL -
but I guess I still prefer a generic solution
Hi Robert / Tom
I think to support GiST with unlogged table we need to do three things:
1. Teach the buffer manager that the LSN of a page not marked
BM_PERMANENT can be ignored
2. Teach GetXLogRecPtrForTemp() to allocate fake LSNs for GiST buffers
using a 64-bit, counter that is persisted
On Tue, Dec 14, 2010 at 5:14 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Dec 14, 2010 at 4:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 14, 2010 at 4:24 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Hmm, the first
Given the foregoing discussion, I see only two possible paths forward here.
1. Just decide that that unlogged tables can't have GIST indexes, at
least until someone figures out a way to make it work. That's sort of
an annoying limitation, but I think we could live with it.
+1
In the small
Robert Haas robertmh...@gmail.com writes:
Given the foregoing discussion, I see only two possible paths forward here.
1. Just decide that that unlogged tables can't have GIST indexes, at
least until someone figures out a way to make it work. That's sort of
an annoying limitation, but I think
On 17.12.2010 21:07, Tom Lane wrote:
IIUC, the problem is that the bufmgr might think that a GIST NSN is an
LSN that should affect when to force out a dirty buffer? What if we
taught it the difference? We could for example dedicate a pd_flags
bit to marking pages whose pd_lsn isn't actually an
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 17.12.2010 21:07, Tom Lane wrote:
IIUC, the problem is that the bufmgr might think that a GIST NSN is an
LSN that should affect when to force out a dirty buffer? What if we
taught it the difference? We could for example
On Fri, Dec 17, 2010 at 2:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
IIUC, the problem is that the bufmgr might think that a GIST NSN is an
LSN that should affect when to force out a dirty buffer? What if we
taught it the difference? We could for
Robert Haas robertmh...@gmail.com writes:
Another possibly-useful thing about mandating a full page header for
every page is that it might give us a way of avoiding unnecessary full
page writes. As I wrote previously:
Could we do that via a bufmgr status bit, instead? Heikki's idea has
the
On Fri, Dec 17, 2010 at 2:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 17.12.2010 21:07, Tom Lane wrote:
IIUC, the problem is that the bufmgr might think that a GIST NSN is an
LSN that should affect when to force out a dirty
On Fri, Dec 17, 2010 at 2:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Another possibly-useful thing about mandating a full page header for
every page is that it might give us a way of avoiding unnecessary full
page writes. As I wrote previously:
Could
On 17.12.2010 21:32, Robert Haas wrote:
I guess the question is whether it's right to conflate table is
unlogged with LSN is fake. It's not immediately obvious to me that
those concepts are isomorphic, although though the reverse isn't
obvious to me either.
The buffer manager only needs to
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 17.12.2010 21:32, Robert Haas wrote:
I guess the question is whether it's right to conflate table is
unlogged with LSN is fake. It's not immediately obvious to me that
those concepts are isomorphic, although though the reverse
On Fri, Dec 17, 2010 at 3:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 17.12.2010 21:32, Robert Haas wrote:
I guess the question is whether it's right to conflate table is
unlogged with LSN is fake. It's not immediately obvious to
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 17, 2010 at 3:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah. I think that BM_UNLOGGED might be a poor choice for the flag name,
just because it overstates what the bufmgr needs to assume.
I was actually thinking of adding BM_UNLOGGED
On Fri, Dec 17, 2010 at 3:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 17, 2010 at 3:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah. I think that BM_UNLOGGED might be a poor choice for the flag name,
just because it overstates what the bufmgr
Robert Haas robertmh...@gmail.com writes:
Allright, what do you want to call the other bit, then? BM_SKIP_XLOG_FLUSH?
Like I said, I'd be tempted to invert the sense, so that the flag is set
for normal relations. Then it becomes something like BM_FLUSH_XLOG.
regards,
[ hit send too soon ... ]
Robert Haas robertmh...@gmail.com writes:
Since these bits will only be set/cleared when the buffer mapping is
changed, can we examine this bit without taking the spinlock?
Only if you're willing for the result to be unreliable. In the
case of the xlog flush bit, I
On Fri, Dec 17, 2010 at 4:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Since these bits will only be set/cleared when the buffer mapping is
changed, can we examine this bit without taking the spinlock?
Only if you're willing for the result to be unreliable.
If we read the bits while someone else
On Sat, Nov 13, 2010 at 9:09 PM, Robert Haas robertmh...@gmail.com wrote:
The fact that it's easy doesn't make it workable. I would point out for
starters that AMs might (do) put WAL locations and/or XIDs into indexes.
Occasionally copying very old LSNs or XIDs back into active files seems
On 14.12.2010 23:06, Robert Haas wrote:
On Sat, Nov 13, 2010 at 9:09 PM, Robert Haasrobertmh...@gmail.com wrote:
The fact that it's easy doesn't make it workable. I would point out for
starters that AMs might (do) put WAL locations and/or XIDs into indexes.
Occasionally copying very old LSNs
On Tue, Dec 14, 2010 at 4:24 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Hmm, the first idea that comes to mind is to use a counter like the
GetXLogRecPtrForTemp() counter I used for temp tables, but global, in shared
memory. However, that's a bit problematic because if we
Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 14, 2010 at 4:24 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Hmm, the first idea that comes to mind is to use a counter like the
GetXLogRecPtrForTemp() counter I used for temp tables, but global, in shared
memory.
On Tue, Dec 14, 2010 at 4:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 14, 2010 at 4:24 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Hmm, the first idea that comes to mind is to use a counter like the
41 matches
Mail list logo
