"Nick Fankhauser" <[EMAIL PROTECTED]> writes:
>> There are a lot of situations where pg_dump fails to pick a safe reload
>> order at the moment (that's why pg_restore has that wild and woolly set
>> of options for manual adjustment of the reload order).
> Is this considered a bug, or a generally a
On 2 Dec 2002 at 15:15, Joe Conway wrote:
> David F. Skoll wrote:
> > No, I'm sure a btree will work. However, won't the index be
> > inefficient (i.e., very flat) if there are many entries with the same
> > value? Or is this not a problem?
> >
>
> If you're concerned, why not try a partial in
David F. Skoll wrote:
No, I'm sure a btree will work. However, won't the index be
inefficient (i.e., very flat) if there are many entries with the same
value? Or is this not a problem?
If you're concerned, why not try a partial index?
Joe
---(end of broadcast)--
On 2 Dec 2002 at 17:10, David F. Skoll wrote:
> I've heard that a btree index performs badly in this situation.
As another poster has shown, it should be OK. I recently dealt with
distributions simlar to your example.
> Is a hash index appropriate? I've heard bad things about hash
> indexes
On Mon, 2 Dec 2002, Joel Burton wrote:
> Looks right to me: index scan for the less-common option, seqscan for
> the most common. Why don't you think this, as a btree, will work for
> you?
No, I'm sure a btree will work. However, won't the index be
inefficient (i.e., very flat) if there are many
On Mon, Dec 02, 2002 at 05:10:00PM -0500, David F. Skoll wrote:
> Hi,
>
> I have a table with a column called "state". Each row can be in one
> of four states, let's call them 'new', 'pending', 'ok', and 'bad'.
> On average, about 95% of the rows will be 'bad', with the remaining
> 5% being in on
Hi,
I have a table with a column called "state". Each row can be in one
of four states, let's call them 'new', 'pending', 'ok', and 'bad'.
On average, about 95% of the rows will be 'bad', with the remaining
5% being in one of the other three states. If the table has 50K rows
and I just want to p
On Mon, 2 Dec 2002, Raymond Chui wrote:
> I created a column, dada type timstamp with time zone
> and with default CURRENT_TIMSTAMP
> it shows me the default is
>
> default ('now'::text)::timstamp(6) with time zone
>
> Then when I insert a row, the default timestamp value is
>
> -mm-dd HH:MM:s
> You could check this by running pg_restore with query logging
> turned on, to see what commands it's actually issuing -- or just do
> "pg_restore -s" into a text file and eyeball the generated script.
I did this, and there is a view created before the table it refers to.
> There are a lot of
On Mon, Dec 02, 2002 at 11:41:33AM -0500, Raymond Chui wrote:
> I created a column, dada type timstamp with time zone
> and with default CURRENT_TIMSTAMP
> it shows me the default is
>
> default ('now'::text)::timstamp(6) with time zone
>
> Then when I insert a row, the default timestamp value is
We don't work with Mosix/beowulf because we use shared memory between
the backends.
---
Mario Medina Nussbaum wrote:
> Hi! i need a cluster of psql databases, i readed about mosix and
> beowulf, but i don't know which one i
Hi! i need a cluster of psql databases, i readed about mosix and
beowulf, but i don't know which one is the right one for that task, or
if there is another one.
Anyone can tell me which one, and give me a clue (or link) on how to
configure it?
Thank you.
smime.p7s
Description: S/MIME Cryptog
On Wed, Nov 27, 2002 at 01:16:35PM -0500, Merlin Moncure wrote:
> I agree 100%: hardware raid sucks.
I've been mostly ignoring this thread, but I'm going to jump in at
this point.
> We confirmed the performance results with heavy testing. There is virtually
> no disadvatage to software raid, ju
On Mon, 2002-12-02 at 14:47, Nick Fankhauser wrote:
> Apparently my first problem is the result of plpgsql already being defined
> in template1. I haven't touched template1 since my install, but it may be
> that template1 comes with this already defined, or it may be that template1
> is set up thi
"Nick Fankhauser" <[EMAIL PROTECTED]> writes:
> It appears that in the process of creating the schema, pg_restore attempted
> to create an object that required the existence of actor, which wasn't
> restored yet. My conjecture is that the objects are just being created in
> the wrong order.
Probab
Hi-
Thanks for the helpful suggestions on this problem last Wednesday morning- I
spent the rest of the day in a meeting, and I'm now returning to the problem
post-holiday. I apologize for the slow response to your ideas.
Tom- You were correct, I was restoring the wrong database in my example with
if you are on linux
copy contrib/start-scripts/linux /etc/rc.d/init.d/postgresql
and as root do:
# chkconfig --add postgresql
# chkconfig postgresql start
if that does not works out you can add following line in
one of your start up scripts usually /etc/rc.d/rc.local
su -l postgres -c "pg_c
> What is the correct method of temporarily
> disabling all triggers from a table?
Disable:
db=# update pg_class set reltriggers = '0' where relname = 'your_table';
Enable:
db=# update pg_class set reltriggers = (select count(*) from pg_trigger
where pg_class.oid = tgrelid) where relname = 'yo
18 matches
Mail list logo
