Heikki Linnakangas wrote:
Tom Lane wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
I also wonder what the performance impact of extending BufferTag is.
That's a fair objection, and obviously something we'd need to check.
But I don't recall seeing hash_any so high on any profile that I
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> More precisely, on CVS HEAD it takes between 7.1-7.2%. After extending
> BufferTag with one uint32, it takes 7.4-7.5%. So the effect is
> measurable if you try hard enough, but not anything to get worried about.
And if we adopt the allegedly-fas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Mar 17, 2008 at 01:23:46PM -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> >> Tom Lane wrote:
> >>> The idea that's becoming attractive to me while contemplating the
> >>> multiple-maps problem is that we should adopt somethi
On Mon, Mar 17, 2008 at 6:23 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I'm not wedded to "forks", that's just the name that was used in the
> only previous example I've seen. Classic Mac had a "resource fork"
> and a "data fork" within each file.
>
> Don't think I like "maps" though, as (a) th
Tom Lane wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
You're cavalierly waving away a whole boatload of problems that will
arise as soon as you start trying to make the index AMs play along
with this :-(.
It doesn't seem very hard.
The problem is that the index
"Tom Lane" <[EMAIL PROTECTED]> writes:
> I'm not wedded to "forks", that's just the name that was used in the
> only previous example I've seen. Classic Mac had a "resource fork"
> and a "data fork" within each file.
fwiw forks are not unique to MacOS, c.f.:
http://en.wikipedia.org/wiki/Fork_%2
On Mon, 2008-03-17 at 13:23 -0400, Tom Lane wrote:
> I'm not wedded to "forks", that's just the name that was used in the
> only previous example I've seen. Classic Mac had a "resource fork"
> and a "data fork" within each file.
>
> Don't think I like "maps" though, as (a) that prejudges what th
On Mon, Mar 17, 2008 at 6:23 PM, Tom Lane wrote:
> Simon Riggs writes:
>>
>> Can we call them "maps" or "metadata maps"? "forks" sounds weird.
>
> I'm not wedded to "forks", that's just the name that was used in the
> only previous example I've seen. Classic Mac had a "resource fork"
> and a "d
On Mon, Mar 17, 2008 at 01:23:46PM -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> >> Tom Lane wrote:
> >>> The idea that's becoming attractive to me while contemplating
> >>> the multiple-maps problem is that we should adopt something
> >>> similar to the old Mac OS idea of mult
On Mon, 2008-03-17 at 13:23 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> >> Tom Lane wrote:
> >>> The idea that's becoming attractive to me while contemplating the
> >>> multiple-maps problem is that we should adopt something similar to
> >>> the old Mac OS idea of multiple "f
Simon Riggs <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> The idea that's becoming attractive to me while contemplating the
>>> multiple-maps problem is that we should adopt something similar to
>>> the old Mac OS idea of multiple "forks" in a relation.
> Can we call them "maps" or "metadata
Gregory Stark <[EMAIL PROTECTED]> writes:
> One advantage of using separate relfilenodes would be that if we need to
> regenerate a map we could do it in a new relfilenode and swap it in like we do
> with heap rewrites.
You could probably do that using a temporary fork number, if the
situation eve
Gregory Stark wrote:
"Tom Lane" <[EMAIL PROTECTED]> writes:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
My original thought was to have a separate RelFileNode for each of the
maps. That would require no smgr or xlog changes, and not very many
changes in the buffer manager, thou
"Tom Lane" <[EMAIL PROTECTED]> writes:
> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
>> My original thought was to have a separate RelFileNode for each of the
>> maps. That would require no smgr or xlog changes, and not very many
>> changes in the buffer manager, though I guess you'd more c
On Sun, 2008-03-16 at 21:33 -0300, Alvaro Herrera wrote:
> Tom Lane wrote:
>
> > The idea that's becoming attractive to me while contemplating the
> > multiple-maps problem is that we should adopt something similar to
> > the old Mac OS idea of multiple "forks" in a relation. In addition
> > to t
On Mon, 2008-03-17 at 09:29 -0400, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > On Sun, 2008-03-16 at 21:33 -0300, Alvaro Herrera wrote:
> >> Tom Lane wrote:
> >>> The idea that's becoming attractive to me while contemplating the
> >>> multiple-maps problem is that we should ado
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> You're cavalierly waving away a whole boatload of problems that will
>> arise as soon as you start trying to make the index AMs play along
>> with this :-(.
> It doesn't seem very hard.
The problem is that the index AMs are n
Tom Lane wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
I've started working on revamping Free Space Map, using the approach
where we store a map of heap pages on every nth heap page. What we need
now is discussion on the details of how exactly it should work.
You're cavalierly wavin
Hannu Krosing <[EMAIL PROTECTED]> writes:
> On Sun, 2008-03-16 at 21:33 -0300, Alvaro Herrera wrote:
>> Tom Lane wrote:
>>> The idea that's becoming attractive to me while contemplating the
>>> multiple-maps problem is that we should adopt something similar to
>>> the old Mac OS idea of multiple "f
On Sun, 2008-03-16 at 21:33 -0300, Alvaro Herrera wrote:
> Tom Lane wrote:
>
> > The idea that's becoming attractive to me while contemplating the
> > multiple-maps problem is that we should adopt something similar to
> > the old Mac OS idea of multiple "forks" in a relation. In addition
> > to
Tom Lane wrote:
> The idea that's becoming attractive to me while contemplating the
> multiple-maps problem is that we should adopt something similar to
> the old Mac OS idea of multiple "forks" in a relation. In addition
> to the main data fork which contains the same info as now, there could
>
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> I've started working on revamping Free Space Map, using the approach
> where we store a map of heap pages on every nth heap page. What we need
> now is discussion on the details of how exactly it should work.
You're cavalierly waving away a whol
I've started working on revamping Free Space Map, using the approach
where we store a map of heap pages on every nth heap page. What we need
now is discussion on the details of how exactly it should work.
Here's my rough plan on the implementation. It's long, sorry. I'm fairly
confident with i
23 matches
Mail list logo
