On Friday the 6th of May 2005, Mr. Treat opined:
> I also don't think it is any harder to learn to query the
> system tables than it would be to learn to query these new
> views (with a few caevets that I will come back to) and it
> might actually be better.
Admin tools are in a sense already a
1:50 PM
To: Rod Taylor
Cc: Darren King; Bruce Momjian; PostgreSQL Development
Subject: Re: [HACKERS] Minor TODO list changes
On Thu, 2004-11-04 at 18:15, Rod Taylor wrote:
> > At some point it would also be nice to be able to mark tables as
> > read-only and then any indexes created on
In my data warehousing situation, I'd like to be able to specify that
the indexes be as compact as possible (fillfactor = 100%) in order to
hit as few index pages as necessary.
For summary tables there will not be any more inserts or deletions so
the index will not change either. In that case, th
> I agree with the notion that "contrib" be removed
> from the main distribution. There is, however, a
> disconnect between supporting projects and the main system.
>
> Take a look at the www.postgresql.org web site.
> Most people visually filter out the side bars. I've
> been looking over effectiv
> "Bob" <[EMAIL PROTECTED]> spewed forth...
>
> We achieved 8 times the performance with exactly the same
> hardware. What the hell is this idiot talking about us
> relying on hardware? He is a moron. You will do everyone
> a favour if you just bounce him off the bottom of your
> killfile.
> ...
>
> You want to process all invoices to count them
> and to sum up the amounts on a per month/area/type
> basis. The initial data size is in GB, but the
> size of the expected result is in KB (namely 2 data
> for each 100 areas * 12 months * 4 types).
The key to handling large datasets for data min
> > Attached is a patch that adds support for specifying a location for
> > indexes via the "create database" command.
> >
> > I believe this patch is complete, but it is my first .
>
> This patch allows index locations to be specified as
> different from data locations. Is this a feature dir
> 3) I am reading the Solaris Internals book and there is mention of a
> "free behind" capability with large sequential scans. When a large
> sequential scan happens that would wipe out all the old cache entries,
> the kernel detects this and places its previous pages first
> on the free list.
>> I am pumping about 200gb a week through the pg database,
>> and our estimated database size is something like 4tb by
>> the end of the year.
>
> Can anyone say 'Woof!'?
Amen, Lamar. I was trying to think of something myself besides
'Wow!'...
As a side note, there's a blurb in the July 16, 20
> I can't see how any configure option would be faster or
> better than the existing command line /config file parameters
> -- it would only serve to make things harder to deal with IMHO.
> "Tuning" PostgreSQL is pretty simple, and is explained pretty
> well throughout the manual (especially in th
> A more promising idea is to hack function creation
> so that the OID assigned to the function is lower
> than the OIDs assigned to any shell types created
> when the function is defined. Or we could try to
> hack pg_dump to fix this, but that doesn't seem
> appetizing.
Requiring OID ordering w
>
> CREATE OPERATOR testbit (
> leftarg = bitset,
> rightarg = int4,
> procedure = testbit,
> commutator = testbit
> );
>
> Now we have a big problem, as the DROP OPERATOR command
> cannot delete the illegally named operator.
Have you tried deleting it directly from pg_operator in
> We could fix this either by adding a new hash function to support
> macaddr, or by removing the pg_amXXX entries that claim macaddr is
> hashable. Either change will not take effect without an initdb,
> however, and I'm loath to force one now that we've started beta.
How about creating an SQL
13 matches
Mail list logo
