Hi Heikki,
On Mon, Feb 11, 2013 at 7:28 PM, Heikki Linnakangas 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 / display t
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
Hi Heikki,
On Mon, Jan 28, 2013 at 2:34 PM, Heikki Linnakangas wrote:
> On 23.01.2013 17:30, Robert Haas wrote:
>
>> On Wed, Jan 23, 2013 at 4:04 AM, Jeevan Chalke
>> >
>> wrote:
>>
>>> I guess my earlier patch, which was directly incrementing
>>>
>>> ControlFile->unloggedLSN counter was the c
On Mon, Jan 28, 2013 at 4:04 AM, Heikki Linnakangas
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 ought to do is force a
On 23.01.2013 17:30, Robert Haas wrote:
On Wed, Jan 23, 2013 at 4:04 AM, Jeevan Chalke
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 of patch I did what Robert ha
On Wed, Jan 23, 2013 at 4:04 AM, Jeevan Chalke
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 suggested. At start of t
On Wed, Jan 16, 2013 at 3:24 AM, Robert Haas wrote:
> On Tue, Jan 15, 2013 at 4:26 PM, Tom Lane wrote:
> > Robert Haas 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 st
On Tue, Jan 15, 2013 at 4:26 PM, Tom Lane wrote:
> Robert Haas 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
>> generalizati
Robert Haas 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 than a special-purpos
On Tue, Jan 15, 2013 at 1:58 PM, Heikki Linnakangas
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 contention
>> for the root
On 2013-01-15 20:58:00 +0200, Heikki Linnakangas wrote:
> On 15.01.2013 20:48, Tom Lane wrote:
> >Robert Haas writes:
> >>On Tue, Jan 15, 2013 at 1:10 PM, Heikki Linnakangas
> >> wrote:
> >>>Could we stash the counter e.g. in the root page of the index?
> >
> >>That would require maintaining a co
On 15.01.2013 20:48, Tom Lane wrote:
Robert Haas writes:
On Tue, Jan 15, 2013 at 1:10 PM, Heikki Linnakangas
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 bad bec
On Tue, Jan 15, 2013 at 1:48 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jan 15, 2013 at 1:10 PM, Heikki Linnakangas
>> 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 counte
Robert Haas writes:
> On Tue, Jan 15, 2013 at 1:10 PM, Heikki Linnakangas
> 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 bad because then we'd need to
> store on
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
On Tue, Jan 15, 2013 at 1:10 PM, Heikki Linnakangas
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() function and added
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.
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 acros
On Fri, Dec 17, 2010 at 4:17 PM, Tom Lane 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 is writing t
[ hit send too soon ... ]
Robert Haas 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 don't believe an extr
Robert Haas 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, tom lane
--
Sent via
On Fri, Dec 17, 2010 at 3:15 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Dec 17, 2010 at 3:03 PM, Tom Lane 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
Robert Haas writes:
> On Fri, Dec 17, 2010 at 3:03 PM, Tom Lane 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 even before this
> discussion, becaus
On Fri, Dec 17, 2010 at 3:03 PM, Tom Lane wrote:
> Heikki Linnakangas 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 isomorphi
Heikki Linnakangas 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 isn't
>> obvious to me ei
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
On Fri, Dec 17, 2010 at 2:31 PM, Tom Lane wrote:
> Robert Haas 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
On Fri, Dec 17, 2010 at 2:22 PM, Tom Lane wrote:
> Heikki Linnakangas 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?
Robert Haas 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 merit that it actual
On Fri, Dec 17, 2010 at 2:07 PM, Tom Lane wrote:
> Robert Haas 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 example dedicate a pd_flags
> bit to mar
Heikki Linnakangas 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 dedicate a pd_flags
>> bit to marki
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
Robert Haas 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 we could live wit
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 s
On Tue, Dec 14, 2010 at 5:14 PM, Robert Haas wrote:
> On Tue, Dec 14, 2010 at 4:55 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Tue, Dec 14, 2010 at 4:24 PM, Heikki Linnakangas
>>> wrote:
Hmm, the first idea that comes to mind is to use a counter like the
GetXLogRecPtrForTemp() c
On Tue, Dec 14, 2010 at 4:55 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Dec 14, 2010 at 4:24 PM, Heikki Linnakangas
>> 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
>>> mem
Robert Haas writes:
> On Tue, Dec 14, 2010 at 4:24 PM, Heikki Linnakangas
> 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 stor
On Tue, Dec 14, 2010 at 4:24 PM, Heikki Linnakangas
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 store a value from
> that counte
On 14.12.2010 23:06, Robert Haas wrote:
On Sat, Nov 13, 2010 at 9:09 PM, Robert Haas 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 acti
On Sat, Nov 13, 2010 at 9:09 PM, Robert Haas 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
>> pretty dangerous
41 matches
Mail list logo
