On Thu, 30 Oct 2003 17:49:08 -0200 (BRST)
"alexandre :: aldeia digital" <[EMAIL PROTECTED]> wrote:
> Both use: Only postgresql on server. Buffers = 8192, effective cache =
> 10
>
Well, I'm assuming you meant 1GB of ram, not 1MB :)
Check a ps auxw to see what is running. Perhaps X is runnin
Jeff wrote:
On Thu, 30 Oct 2003 17:49:08 -0200 (BRST)
"alexandre :: aldeia digital" <[EMAIL PROTECTED]> wrote:
Both use: Only postgresql on server. Buffers = 8192, effective cache =
10
Well, I'm assuming you meant 1GB of ram, not 1MB :)
Check a ps auxw to see what is running. Perhaps X is ru
On Wed, 29 Oct 2003 10:17:24 -0500, Rod Taylor <[EMAIL PROTECTED]> wrote:
>On Wed, 2003-10-29 at 09:03, Robert Treat wrote:
>> Indexes: entity_watch_map_pkey primary key btree (entity_id, watch_id),
>> ewm_entity_id btree (entity_id),
>>
>> I can't think of why the second index is there,
Scott, Jeff and Shridhar:
1 GB RAM :)
The stock kernels are not the same, HyperThreading enabled. 80
simultaneous connections. sort_mem = 4096
I will compile my own kernel on this weekend, and I will report
to the list after.
Thank's all
Alexandre
> Also are two kernels exactly same? In my e
On Fri, Oct 31, 2003 at 12:03:59PM -0200, alexandre :: aldeia digital wrote:
> Scott, Jeff and Shridhar:
>
> 1 GB RAM :)
>
> The stock kernels are not the same, HyperThreading enabled. 80
Some people have reported that things actually slow down with HT
enabled. Have you tried turning it off?
A
Not being one to hijack threads, but I haven't heard of this performance hit
when using HT, I have what should all rights be a pretty fast server, dual
2.4 Xeons with HT 205gb raid 5 array, 1 gig of memory. And it is only 50% as
fast as my old server which was a dual AMD MP 1400's with a 45gb raid
On Fri, 31 Oct 2003 09:31:19 -0600
"Rob Sell" <[EMAIL PROTECTED]> wrote:
> Not being one to hijack threads, but I haven't heard of this
> performance hit when using HT, I have what should all rights be a
> pretty fast server, dual 2.4 Xeons with HT 205gb raid 5 array, 1 gig
> of memory. And it is
Jeff wrote:
On Fri, 31 Oct 2003 09:31:19 -0600
"Rob Sell" <[EMAIL PROTECTED]> wrote:
Not being one to hijack threads, but I haven't heard of this
performance hit when using HT, I have what should all rights be a
pretty fast server, dual 2.4 Xeons with HT 205gb raid 5 array, 1 gig
of memory. And i
Just for an additional viewpoint. I'm finishing up a project based on FreeBSD
and PostgreSQL. The target server is a Dual 2.4G Intel machine. I have tested
the application with hyperthreading enabled and disabled. To all appearances,
enabling hyperthreading makes the box act like a quad, with t
Yet another question.. thanks to everyone responding to all these so far.. ;)
This one is basically.. given I have a big table already in COPY format,
about 28 million rows, all keys guaranteed to be unique, I'm trying to find
out which of the following will get the import finished the fastest:
If it is 7.4 beta 5 or later, I would definitely go with A.
Adding indexes after the fact seems to be much quicker. Foreign keys use
the same algorithm prior to beta 5 regardless of timing.
A primary key and unique index will have approx the same performance (a
check for NULL isn't very costly).
Bill Moran <[EMAIL PROTECTED]> writes:
> Just for an additional viewpoint. I'm finishing up a project based on FreeBSD
> and PostgreSQL. The target server is a Dual 2.4G Intel machine. I have tested
> the application with hyperthreading enabled and disabled. To all appearances,
> enabling hype
For the record I am running on SuSE with a pretty much stock kernel. Not to
sound naïve, but is turning of HT something done in the bios?
Rob
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bill Moran
Sent: Friday, October 31, 2003 9:56 AM
To: [EMAIL PROT
Greg Stark wrote:
Bill Moran <[EMAIL PROTECTED]> writes:
Just for an additional viewpoint. I'm finishing up a project based on FreeBSD
and PostgreSQL. The target server is a Dual 2.4G Intel machine. I have tested
the application with hyperthreading enabled and disabled. To all appearances,
ena
On Fri, Oct 31, 2003 at 10:42:06AM -0600, Rob Sell wrote:
> For the record I am running on SuSE with a pretty much stock kernel. Not to
> sound na?ve, but is turning of HT something done in the bios?
As far as I know, yes.
A
--
Andrew Sullivan 204-4141 Yonge Street
Allen,
> a) CREATE TABLE with no indexes or keys. Run the COPY (fast, ~30min), then
> CREATE INDEX on each column it's needed on, and ALTER TABLE for the pk and
> each fk needed.
Did you ANALYZE after the copy?
> If there isn't a significant difference between all of them, performance
> wise, I
At 12:10 10/31/2003, Josh Berkus wrote:
Allen,
> a) CREATE TABLE with no indexes or keys. Run the COPY (fast, ~30min), then
> CREATE INDEX on each column it's needed on, and ALTER TABLE for the pk and
> each fk needed.
Did you ANALYZE after the copy?
No, and this was my major mistake. I normally
Nope, still 7.3.4 here.. I am very excited about 7.4 though.. almost as
excited as I am about FreeBSD 5.x going -STABLE.. it's a close race
between the two..
I'll keep this in mind for when I update though, thanks.
At 11:23 10/31/2003, Rod Taylor wrote:
If it is 7.4 beta 5 or later, I would de
On Fri, 2003-10-31 at 13:27, Allen Landsidel wrote:
> I had no idea analyze was playing such a big role in this sense.. I really
> thought that other than saving space, it wasn't doing much for tables that
> don't have indexes on the.
ANALYZE doesn't save any space at all -- VACUUM is probably w
On Fri, 2003-10-31 at 11:37, Greg Stark wrote:
> My understanding is that the case where HT hurts is precisely your case. When
> you have two real processors with HT the kernel will sometimes schedule two
> jobs on the two virtual processors on the same real processor leaving the two
> virtual proc
Allen,
> I had no idea analyze was playing such a big role in this sense.. I really
> thought that other than saving space, it wasn't doing much for tables that
> don't have indexes on the.
Among other things, ANALYZE tells postgres how many rows are in the table. So
if you add a PK constraint
At 13:40 10/31/2003, Neil Conway wrote:
On Fri, 2003-10-31 at 13:27, Allen Landsidel wrote:
> I had no idea analyze was playing such a big role in this sense.. I really
> thought that other than saving space, it wasn't doing much for tables that
> don't have indexes on the.
ANALYZE doesn't save any
We had a problem at work that when a windows box would connect to a samba
share with a lot of files in it, the kswapd was going nuts, even though we
weren't low on memory at all. Updating to the 2.4.18 or so of the later
redhats fixed that issue. It might be related. I think the kflush daemon
is there any way to update the stats inside a transaction? what i have is
something like:
select count(*) from foo;
-> 0
begin;
copy foo from '/tmp/foo'; -- about 100k rows
-- run some queries on foo which perform horribly because the stats
-- are way off (100k rows v. 0 rows)
commit;
it see
Hello all!
Do anyone have experience installing Postgres 7.3.4 on Slackware 9.1?
Do exist any trouble, bug, problem... or is a good MIX?
I want to "leave" RedHat (9) because is not "free" anymore and i don't
want to use fedora BETA TEST versions.
Any suggestion?
THANKS ALL.
--
> begin;
> analyze foo;
> ERROR: ANALYZE cannot run inside a BEGIN/END block
>
> i am using version 7.2.3.
Time to upgrade. 7.3 / 7.4 allows this to happen.
signature.asc
Description: This is a digitally signed message part
Hi!
I haven´t really tested it on Slackware 9.1. But i am running
Postgresql now for over two years on various Slackware versions.
My current server is running on Slackware 8.0 with a lot of packages
(especially the core libs) upgraded to slack 9.1 packages.
I had never problems with postgresql r
Chester Kustarz <[EMAIL PROTECTED]> writes:
> it seems that you cannot run analyze inside a transaction:
You can in 7.3.* ...
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unreg
Well Sorry everyone ,
The problem was tracked down to a silly
datatype mismatch between two join columns
in table Groups(instance) and Tickets(id)
(int vs varchar )
7.4b5 is automatically taking care of this
mismatch hence it was getting executed there.
But , The problem is will this behaviour
On Thu, Oct 30, 2003 at 10:28:10AM -0700, [EMAIL PROTECTED] wrote:
> Does xfs_freeze work on red hat 7.3?
It works on any kernel with XFS (it talks directly to XFS).
cheers.
--
Nathan
---(end of broadcast)---
TIP 2: you can get off all lists at o
30 matches
Mail list logo