Hey,
Just wondering if there is currently any mechanism in the contrib makefile
hierarchy for installing header files into an appropriate directory. I didn't
find anything.
I'm using PGSphere (spherical types/operators), and trying to help them out a
little here and there. When I converted my
On Friday 22 August 2003 18:42, Josh Berkus wrote:
> Bad link. This gives me a post by Lamar Owen talking about usng OIDs to
> name files.
I think he may be referring to the last paragraph. Vadim had said that the
tablenames would go to OIDs. They have always been individual files. Been a
lo
How can I --enable-thread-safety and JUST need the getpwuid_r function and
not the strerror_r and gethostbyname_r function?
UnixWare doesn't have strerror_r and gethostbyname_r, and we DONT NEED THEM!
Please help me fix this.
Also, Olivier is right, there is an issue with the unixware template.
On Fri, 22 Aug 2003, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On 22 Aug 2003, Greg Stark wrote:
> >> If it's deemed a reasonable approach and nobody has any fatal flaws then I
> >> expect it would be useful to put in the contrib directory?
>
> > I'm not sure that ERROR if th
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On 22 Aug 2003, Greg Stark wrote:
>> If it's deemed a reasonable approach and nobody has any fatal flaws then I
>> expect it would be useful to put in the contrib directory?
> I'm not sure that ERROR if the locale cannot be put back is sufficient
> (alth
On 22 Aug 2003, Greg Stark wrote:
>
> So, I needed a way to sort using collation rules other than the one the
> database was built with. So I wrote up the following function exposing strxfrm
> with an extra parameter to specify the LC_COLLATE value to use.
>
> This is my first C function so I'm r
Greg Stark writes:
> This is my first C function so I'm really unsure that I've done the right
> thing. For the most part I pattern-matched off the string_io code in the
> contrib directory.
That was just about the worst example you could have picked. Please
forget everything you have seen and s
Mike,
> Vadim seemed to think differently:
>
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=00030722102200.00601%40lorc.wgcr.org&rnum=9&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26q%3DVadim%2Bsingle%2Bfile%2Bpostgres
Bad link. This gives me a post by Lamar Owe
So, I needed a way to sort using collation rules other than the one the
database was built with. So I wrote up the following function exposing strxfrm
with an extra parameter to specify the LC_COLLATE value to use.
This is my first C function so I'm really unsure that I've done the right
thing. F
Just want to add my $0.03 on that.
single file DB has some benefits as:
1. ability to allocate one continues chunk on disk,
significantly reduces disk seeks,
mostly ancestral but still true today ( I still see DB living on none
arrays )
2. And of cause countless design considerations.
Say
Josh Berkus wrote:
> Jan,
>
> In my experience (a lot of MS SQL, more MS Access than I want to talk about,
> and a little Oracle) corruption failures on single-file databases are more
> frequent than databases which depend on the host OS, and such failures are
> much more severe when the occur.
Jan,
> If a filesystem contains only very few big files (and nothing else) and
> these files do not grow or shrink during normal operation and are really
> fully allocated in the block tables, then said filesystems metadata does
> not change and that means that the filesystem will never ever be
On Friday, August 22, 2003, at 12:07 PM, Josh Berkus wrote:
Single-file databases also introduce a number of problems:
1) The database file is extremely vulnerable to corruption, and if
corruption
occurs it is usually not localized but destroys the entire database
due to
corruption of the inter
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
Okay, my proposal would be to have a VACUUM mode where it tells the
buffer manager to only return a page if it is already in memory, and
some "not cached" if it would have to read it from disk, and simply skip
the page in that case.
Since no
Jan Wieck <[EMAIL PROTECTED]> writes:
> Okay, my proposal would be to have a VACUUM mode where it tells the
> buffer manager to only return a page if it is already in memory, and
> some "not cached" if it would have to read it from disk, and simply skip
> the page in that case.
Since no such ca
On Fri, 22 Aug 2003 12:18:02 -0400, Jan Wieck <[EMAIL PROTECTED]>
wrote:
>Okay, my proposal would be to have a VACUUM mode where it tells the
>buffer manager to only return a page if it is already in memory
But how can it know? Yes, we know exactly what we have in PG shared
buffers. OTOH we kee
Some well known database that is very popular amongst people who care
more for their data than for license fees uses few very big files that
are statically allocated (if using files instead of raw devices).
Sure does Oracle internally maintain some sort of filesystem. But this
is more due to ot
On Fri, 22 Aug 2003 10:45:50 -0400, Tom Lane <[EMAIL PROTECTED]>
wrote:
>One big question mark in my mind about these "partial vacuum"
>proposals is whether they'd still allow adequate FSM information to be
>maintained. If VACUUM isn't looking at most of the pages, there's no
>very good way to acq
Okay, my proposal would be to have a VACUUM mode where it tells the
buffer manager to only return a page if it is already in memory, and
some "not cached" if it would have to read it from disk, and simply skip
the page in that case. Probably needs some modifications in vacuums FSM
handling, but
On Fri, 2003-08-22 at 10:45, Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> Right. One big question mark in my mind about these "partial vacuum"
> proposals is whether they'd still allow adequate FSM information to be
> maintained. If VACUUM isn't looking at most of the pages, there's
Guys,
> >BTW any comments on storing an entire database in single file? I don't
> > trust any file system for performance and data integrity if I have single
> > 100GB file. I would rather have multiple of them..
>
> I don't see why not. Entire file systems are stored within a single file
> someti
On Fri, 2003-08-22 at 11:17, Shridhar Daithankar wrote:
> On 22 Aug 2003 at 11:03, Jan Wieck wrote:
> > That's why I think it needs one more pg_stat column to count the number
> > of vacuumed tuples. If one does
> >
> > tuples_updated + tuples_deleted - tuples_vacuumed
> >
> > he'll get app
On Fri, 2003-08-22 at 11:08, Jan Wieck wrote:
> > Another way to give autovacuum some hints would be to return some number
> > as commandtuples from vacuum. like the number of tuples actually
> > vacuumed. That together with the new number of reltuples in pg_class
> > will tell autovacuum how fr
On 22 Aug 2003, Greg Stark wrote:
>
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Finally, I suspect that once we get rid of the O(N^2) behavior in the
> > executor, we will find that the next biggest bottleneck is in the
> > planner; adding more work for it to do per OR-clause item will make
> > t
Folks,
Howdy! Meet Enrico, who will soon be subscribing to the list.
Enrico wants to implement a new kind of indexing on PostgreSQL, and will do
the programming, provided that he can get some help with the PostgreSQL code.
The catch is that he would do better if someone could help who knew
Tom Lane <[EMAIL PROTECTED]> writes:
> Finally, I suspect that once we get rid of the O(N^2) behavior in the
> executor, we will find that the next biggest bottleneck is in the
> planner; adding more work for it to do per OR-clause item will make
> things worse not better.
But time spent in the
On 22 Aug 2003 at 11:03, Jan Wieck wrote:
> Tom Lane wrote:
>
> > Jan Wieck <[EMAIL PROTECTED]> writes:
> >> Shridhar Daithankar wrote:
> >>> Umm.. What does FSM does then? I was under impression that FSM stores page
> >>> pointers and vacuum work on FSM information only. In that case, it wouldn
Jan Wieck wrote:
Another way to give autovacuum some hints would be to return some number
as commandtuples from vacuum. like the number of tuples actually
vacuumed. That together with the new number of reltuples in pg_class
will tell autovacuum how frequent a relation really needs scanning.
Whi
On 21 Aug 2003 at 16:42, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > Within the scope of the new hashed IN stuff I believe so in at least some
> > cases. I have a few million row table of integers where searching for
> > values IN (~1 values) takes longer than creating the
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
Shridhar Daithankar wrote:
Umm.. What does FSM does then? I was under impression that FSM stores page
pointers and vacuum work on FSM information only. In that case, it wouldn't
have to waste time to find out which pages to clean.
It's the o
On 22 Aug 2003 at 10:45, Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Shridhar Daithankar wrote:
> >> Umm.. What does FSM does then? I was under impression that FSM stores page
> >> pointers and vacuum work on FSM information only. In that case, it wouldn't
> >> have to waste time
Jan Wieck <[EMAIL PROTECTED]> writes:
> Shridhar Daithankar wrote:
>> Umm.. What does FSM does then? I was under impression that FSM stores page
>> pointers and vacuum work on FSM information only. In that case, it wouldn't
>> have to waste time to find out which pages to clean.
> It's the other
Shridhar Daithankar wrote:
On Friday 22 August 2003 16:23, Manfred Koizar wrote:
On Fri, 22 Aug 2003 12:15:33 +0530, "Shridhar Daithankar"
<[EMAIL PROTECTED]> wrote:
>> Which leads us to a zero gravity vacuum, that does the lazy vacuum for
>> pages currently available in the buffer cache only. [.
On Fri, 22 Aug 2003 16:27:53 +0530, Shridhar Daithankar
<[EMAIL PROTECTED]> wrote:
>What does FSM does then?
FSM = Free Space Map. VACUUM writes information into the FSM, INSERTs
consult the FSM to find pages with free space for new tuples.
> I was under impression that FSM stores page
>pointer
> On Friday 22 August 2003 13:59, Andrew Dunstan wrote:
>> Shridhar Daithankar wrote:
>> >BTW any comments on storing an entire database in single file? I
>> >don't
>> > trust any file system for performance and data integrity if I have
>> > single 100GB file. I would rather have multiple of them..
On Friday 22 August 2003 16:23, Manfred Koizar wrote:
> On Fri, 22 Aug 2003 12:15:33 +0530, "Shridhar Daithankar"
>
> <[EMAIL PROTECTED]> wrote:
> >> Which leads us to a zero gravity vacuum, that does the lazy vacuum for
> >> pages currently available in the buffer cache only. [...]
> >
> >Since au
On Friday 22 August 2003 13:59, Andrew Dunstan wrote:
> Shridhar Daithankar wrote:
> >BTW any comments on storing an entire database in single file? I don't
> > trust any file system for performance and data integrity if I have single
> > 100GB file. I would rather have multiple of them..
>
> I don
Shridhar Daithankar wrote:
BTW any comments on storing an entire database in single file? I don't trust
any file system for performance and data integrity if I have single 100GB file.
I would rather have multiple of them..
I don't see why not. Entire file systems are stored within a single fi
38 matches
Mail list logo
