2008/10/2 Tom Lane <[EMAIL PROTECTED]>
> "=?ISO-8859-5?B?svbi0Nv22SDC2Nzn2OjY3Q==?=" <[EMAIL PROTECTED]> writes:
> > delete from company where id not in (select company_id from
> company_descr);
> > I've tried to analyze command, but unlike to other RDBM I've used it did
> not
> > include cascade
I played with work_mem and setting work_mem more than 256000 do not change
the performance.
I try to upgrade to 8.3 using etch-backports but it's a new install not an
upgrade.
So i have to create users, permissions, import data again, it scared me so
i want to find another solutions first.
But now
"=?ISO-8859-5?B?svbi0Nv22SDC2Nzn2OjY3Q==?=" <[EMAIL PROTECTED]> writes:
> delete from company where id not in (select company_id from company_descr);
> I've tried to analyze command, but unlike to other RDBM I've used it did not
> include cascade deletes/checks into query plan. That is first proble
Hello.
I have a database with company table that have a bunch of related
(delete=cascade) tables.
Also it has 1<->M relation to company_descr table.
Once we've found that ~half of our companies do not have any description and
we would like to remove them.
First this I've tried was
delete from comp
Tommy Gildseth wrote:
> Richard Huxton wrote:
>> [EMAIL PROTECTED] wrote:
>>> Thanks,
>>>
>>> Unfornatly, i can't update pgsql to 8.3 since it's not in debian stable.
>>
>> That's why backports.org was invented :-)
>> Or does can't mean "not allowed to"?
>
> Well, running production servers from b
Richard Huxton wrote:
[EMAIL PROTECTED] wrote:
Thanks,
Unfornatly, i can't update pgsql to 8.3 since it's not in debian stable.
That's why backports.org was invented :-)
Or does can't mean "not allowed to"?
Well, running production servers from backports can be a risky
proposition too, an
[EMAIL PROTECTED] wrote:
> Thanks,
>
> Unfornatly, i can't update pgsql to 8.3 since it's not in debian stable.
That's why backports.org was invented :-)
Or does can't mean "not allowed to"?
> So i'm going to play with work_mem & shared_buffers.
>
> With big shared_buffers pgsql tells me
> shm
Thanks,
Unfornatly, i can't update pgsql to 8.3 since it's not in debian stable.
So i'm going to play with work_mem & shared_buffers.
With big shared_buffers pgsql tells me
shmget(cle=5432001, taille=11183431680, 03600).
so i do "echo 13183431680 > /proc/sys/kernel/shmmax" ( 10Go + 2Go just
in
H. William Connors II wrote:
> fa_assignment has 44184945 records
> fa_assignment_detail has 82196027 records
>
> explain select * from fa_assignment fa JOIN fa_assignment_detail fad ON
> (fad.assignment_id = fa.assignment_id) where fa.scenario_id = 0;
>
>
