Bruce Momjian pgman@candle.pha.pa.us wrote:
- Is fillfactor useful for hash and gist indexes?
I think hash does not need it, but gist might need it.
Not sure. We don't know what type of index a GIST will be so we have no
way of knowing. I am thinking we can implement just btree now
Ühel kenal päeval, K, 2006-02-01 kell 18:08, kirjutas Tom Lane:
Hannu Krosing [EMAIL PROTECTED] writes:
Does ALTER TABLE SET TABLESPACE lock the table
It had better ... see nearby discussion about relaxing locking for
TRUNCATE.
Is it some recent disussion ?
Exactly the same problem
Hannu Krosing wrote:
Ühel kenal päeval, K, 2006-02-01 kell 18:08, kirjutas Tom Lane:
Hannu Krosing [EMAIL PROTECTED] writes:
Does ALTER TABLE SET TABLESPACE lock the table
It had better ... see nearby discussion about relaxing locking for
TRUNCATE.
Is it some recent
I am working on an issue that I deal with a lot, there is of course a
standard answer, but maybe it is something to think about for PostgreSQL
9.0 or something. I think I finally understand what I have been fighting
for a number of years. When I have been grousing about postgresql
configuration,
On Thu, 2006-02-02 at 10:23 -0500, Mark Woodward wrote:
If one db is REALLY REALLY huge and doesn't change, and a few
others are small and change often, pg_dumpall will spend most of its time
dumping the unchanging data.
My usual backup strategy does pg_dumpall -g to get the (tiny) global
Mark Woodward [EMAIL PROTECTED] writes:
One of the problems with the current PostgreSQL design is that all the
databases operated by one postmaster server process are interlinked at
some core level. They all share the same system tables. If one database
becomes corrupt because of disk or
Mark Woodward [EMAIL PROTECTED] writes:
One of the problems with the current PostgreSQL design is that all the
databases operated by one postmaster server process are interlinked at
some core level. They all share the same system tables. If one database
becomes corrupt because of disk or
Mark Woodward wrote:
Mark Woodward [EMAIL PROTECTED] writes:
One of the problems with the current PostgreSQL design is that all the
databases operated by one postmaster server process are interlinked at
some core level. They all share the same system tables. If one database
becomes corrupt
Hi all,
After spending some time (~2 days to fully(?) understand the process)
setting up a standby machine using WAL shipping and experimentations to
be fairly sure it is working reliably, I started thinking of how I would
like it to be done.
My dream-process of setting up a standby would be:
Mark Woodward wrote:
Seriously? No use at all? You don't see any purpose in controlling and
managing multiple postgresql postmaster processes from one central point?
I'd rather spend effort in fixing the problems that arise from big
databases; for example Hannu's patch for concurrent vacuum
On Thu, 2 Feb 2006, Mark Woodward wrote:
Now, the answer, obviously, is to create multiple postgresql database
clusters and run postmaster for each logical group of databases, right?
That really is a fine idea, but
Say, in pgsql, I do this: \c newdb It will only find the database that I
I wanted to chime in that I also see this speedup from using XLC 6.0
(IBM's cc), even in 32bit mode. I have tested on AIX 5.2 and 5.1.
I think this would be good to include in the regular release.
Not sure how many people are running older versions of AIX that would
want a new version of
ITAGAKI Takahiro wrote:
Bruce Momjian pgman@candle.pha.pa.us wrote:
- Is fillfactor useful for hash and gist indexes?
I think hash does not need it, but gist might need it.
Not sure. We don't know what type of index a GIST will be so we have no
way of knowing. I am thinking
Rocco Altier wrote:
I wanted to chime in that I also see this speedup from using XLC 6.0
(IBM's cc), even in 32bit mode. I have tested on AIX 5.2 and 5.1.
I think this would be good to include in the regular release.
Not sure how many people are running older versions of AIX that would
On Thu, 2 Feb 2006, Mark Woodward wrote:
Now, the answer, obviously, is to create multiple postgresql database
clusters and run postmaster for each logical group of databases, right?
That really is a fine idea, but
Say, in pgsql, I do this: \c newdb It will only find the database that
On Thu, Feb 02, 2006 at 02:05:03PM -0500, Mark Woodward wrote:
My issue is this, (and this is NOT a slam on PostgreSQL), I have a number
of physical databases on one machine on ports 5432, 5433, 5434. All
running the same version and in fact, installation of PostgreSQL.
One way of acheiving
On Wed, Feb 1, 2006 at 10:50 am, in message
[EMAIL PROTECTED], Bruce Momjian
pgman@candle.pha.pa.us wrote:
Kevin Grittner wrote:
We found a bug in the code from my first patch. Since it was a low
frequency, non- destructive type of problem for us, I was able to
take my
time and look over
Mark,
Even though they run on the same machine, run the same version of the
software, and are used by the same applications, they have NO
interoperability. For now, lets just accept that they need to be on
separate physical clusters because some need to be able to started and
stopped while
Dear hackers
I have downloadedand instaled
pgadim2 (and pgadmin3 corrected for my Windows98 -second
edition) .When I
try to conect my web server,where
I have an AVL program
to nurse and inspect an error message comes and I cannot proceed with the
inspection.
The error is " Column
Mark Woodward wrote:
My issue is this, (and this is NOT a slam on PostgreSQL), I have a number
of physical databases on one machine on ports 5432, 5433, 5434. All
running the same version and in fact, installation of PostgreSQL.
Even though they run on the same machine, run the same version of
Mark Woodward wrote:
From an administration perspective, a single point of admin would
seem like a logical and valuable objective, no?
I don't understand why you are going out of your way to separate your
databases (for misinformed reasons, it appears) and then want to design
a way to
I've written some complicated queries that I'd like to save inside
the server and then call from my clients using a short name. For the
queries that require no external information, views are perfect. For
queries that *do* require external information (like a search date
range), I've used
On Fri, Jan 27, 2006 at 01:12:35PM -0500, Greg Stark wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
David I don't get this... what are you copying from/to that would
wouldn't just script? If you throw into a script you can change
the delimiter on the fly using translation.
The
Kevin Grittner wrote:
to generalize it. As far as I can tell from some testing today,
everything works fine issuing statements through a connection, but
psql
isn't settled down.
Sounds like you made great progress!
Thanks. It was actually pretty easy once I took the time to learn
I believe pgAdmin only supports PostgreSQL 7.3 and above.
Chris
Flavio Caiuby wrote:
Dear hackers
I have downloaded and instaled pgadim2 (and pgadmin3 corrected for my
Windows98 -second edition) .When I
try to conect my web server, where I have an AVL program
to nurse and inspect an
Greetings,
I've just run smack-dab into the bug described here:
http://archives.postgresql.org/pgsql-interfaces/2002-05/msg00083.php
and it's somewhat frustrating since the end of that thread is a
reasonably small patch which fixes the problem:
* Stephen Frost ([EMAIL PROTECTED]) wrote:
and it's somewhat frustrating since the end of that thread is a
reasonably small patch which fixes the problem:
http://archives.postgresql.org/pgsql-interfaces/2002-05/msg00083.php
Erp, not quite sure how I managed that, the end of the thread
Mark Woodward wrote:
From an administration perspective, a single point of admin would
seem like a logical and valuable objective, no?
I don't understand why you are going out of your way to separate your
databases (for misinformed reasons, it appears) and then want to design
a way to
Greetings,
I am writing some plugin for pq. After running ./configure and make, shall I
just go to /src/bin/psql to execute my executable psql -U (usrname) dbname?
It seems that my updates in the file parse_expr.c is not reflect in this
executable? For example, I changed one line from
if
Chris Campbell [EMAIL PROTECTED] writes:
What do you think? Is this an interesting feature? Is this the right way to
go
about it, or should I try to get the planner to see through SQL function
boundaries
The right way to go about this in the original abstract set-theoretic
mindset of SQL
On Feb 2, 2006, at 23:33, Greg Stark wrote:
The right way to go about this in the original abstract set-
theoretic
mindset of SQL is to code the view to retrieve all the rows and
then apply
further WHERE clause restrictions to the results of the view.
So for example this:
CREATE VIEW
Flavio Caiuby [EMAIL PROTECTED] writes:
The error is Column datpathdoes not exist .
You need a newer version of pgadmin --- pg_database.datpath went away
in PG 8.0, but older versions of pgadmin don't know about that.
regards, tom lane
---(end
John wrote:
I am writing some plugin for pq. After running ./configure and make,
shall I just go to /src/bin/psql to execute my executable psql -U
(usrname) dbname? It seems that my updates in the file parse_expr.c
is not reflect in this executable?
Evidently you're not (only) writing a
Chris Campbell schrieb:
...
That was a very simplistic example and didn't illustrate my point -- I
apologize. I was trying to think of something succinct and illustrative
for a quick mailing list post but came up short.
Maybe a better example would be a situation where you want to do
Mark Woodward schrieb:
...
Unless you can tell me how to insert live data and indexes to a cluster
without having to reload the data and recreate the indexes, then I hardly
think I am misinformed. The ad hominem attack wasn't nessisary.
I see you had a usecase for something like pg_diff and
35 matches
Mail list logo
