Qing Zhao <[EMAIL PROTECTED]> writes:
> We have got a G5 64-bit processor to replace an old G4 32-bit
> processor. Given everything else equal, should we see a big
> improvement on PG's performance?
Nope. Database performance typically depends on disk performance first,
and RAM size second. A 6
On Mon, 5 Apr 2004, Rosser Schwarz wrote:
> while you weren't looking, Kevin Barnard wrote:
>
> > Have you added indexes for the custid column for tables
> > account.acct accunt.orgacct and note?
>
> They were indexed in the original case, yes. There was no
> need to index them in today's test ca
Hi,
We have got a G5 64-bit processor to replace an old G4 32-bit
processor. Given everything
else equal, should we see a big improvement on PG's performance?
The other question I have is that, when I tried different size for
shared_buffer ( i used 10,000,
1,000, 528, 256) and Max connections
On Mon, 5 Apr 2004, Kevin Barnard wrote:
> On 5 Apr 2004 at 12:05, Rosser Schwarz wrote:
>
> > Just this morning, however, I created a copy of the target table (all
> > 4.7M rows), with absolutely no foreign keys referring to it, and ran
> > the update against the copy. That update took 2300 sec
while you weren't looking, Kevin Barnard wrote:
> Have you added indexes for the custid column for tables
> account.acct accunt.orgacct and note?
They were indexed in the original case, yes. There was no
need to index them in today's test case, as that was done
purely in attempt to rule in or o
Heiko Kehlenbrink wrote:
i use suse 8.1
postgresql 7.2 compiled from the rpms for using postgis, but that is
Try v7.4, there are many performance improvements. It may not make up
all the differences but it should help.
---(end of broadcast)---
On 5 Apr 2004 at 12:05, Rosser Schwarz wrote:
> Just this morning, however, I created a copy of the target table (all
> 4.7M rows), with absolutely no foreign keys referring to it, and ran
> the update against the copy. That update took 2300 seconds. The
> join columns were indexed in both cases
You're absolutely correct that the general rule is to lead a composite index
with the highest cardinality index columns for fastest selectivity. Indices
and all physical design are based on usage. In this case of unique indices
supporting primary keys in a hierarchy, it depends. For selection of sm
On 5 Apr 2004 at 8:36, Josh Berkus wrote:
>
> Point taken, though, SQL Server has done a better job in opitimizing for
> "dumb" queries. This is something that PostgreSQL needs to work on, as is
> self-referential updates for large tables, which also tend to be really slow.
> Mind you, in
Gary Doades wrote:
Has anyone else done any comparative testing with the 2.6 kernel?
I know for a fact that certain stuff is recognized differently between
2.2, 2.4 and 2.6 kernels.
For example i have one box that i installed debian stable on that used a
2.2 kernel which automatically tuned on
*statistics target = 100
*INFO: index "timeseries_tsid" now contains *16,677,521* row versions
in 145605 pages
DETAIL: 76109 index pages have been deleted, 2 are currently reusable.
CPU 12.00s/2.83u sec elapsed 171.26 sec.
INFO: "timeseries": found 0 removable, 16677521 nonremovable row
v
Thanks Stephan and Tom for your responses. We have been busy, so I haven't
had time to do any further research on this till yesterday. I found that the
large number of triggers on the parent or master table were foreign key
triggers for each table back to the child tables (update and delete on
Jeff wrote:
I think it was on this list - someone posted a message about SETOF
being slower. Tom replied saying it was because it needed to create an
on-disk tuplestore.
I was just looking for some clarification - a SETOF function will always
write the reslting tuples to disk (Not buffering i
After deinstalling and scrubbing PostgreSQL from my server and doing
a clean build using a vanilla 7.4.2 tree, I'm rather more confident
that foreign key validation is at cause in my performance problems.
I recreated my schemas and ran the original update, with foreign
keys referring to the identi
On 4 Apr, Cott Lang wrote:
> On Sun, 2004-04-04 at 01:56, Gary Doades wrote:
>> Unfortunately I don't understand the question!
>>
>> My background is the primarily Win32. The last time I used a *nix OS
>> was about 20 years ago apart from occasional dips into the linux OS
>> over the past few y
"Heiko Kehlenbrink" <[EMAIL PROTECTED]> writes:
> i use suse 8.1
> postgresql 7.2 compiled from the rpms for using postgis, but that is
> anothe story...
7.4 might be a little quicker; but in any case you should be doing this
sort of comparison using the current release, no?
I think it was on this list - someone posted a message about SETOF
being slower. Tom replied saying it was because it needed to create an
on-disk tuplestore.
I was just looking for some clarification - a SETOF function will
always write the reslting tuples to disk (Not buffering in say a
sor
Mike,
> I think it is also possible that Microsoft has more programmers working
> on tuning issues for SQL Server than PostgreSQL has working on the
> whole project.
Ah, but quantity != quality.Or they wouldn't be trolling our mailing lists
trying to hire PostgreSQL programmers for the SQL S
Heiko Kehlenbrink wrote:
hi list,
i want to convince people to use postgresql instead of ms-sql server, so i
set up a kind of comparission insert data / select data from postgresql /
ms-sql server
the table i use was pretty basic,
id bigserial
dist float8
x float8
y float8
z float
hi list,
i want to convince people to use postgresql instead of ms-sql server, so i
set up a kind of comparission insert data / select data from postgresql /
ms-sql server
the table i use was pretty basic,
id bigserial
dist float8
x float8
y float8
z float8
i filled the table wit
Heiko,
> 100.000 from 50.000.000:
>
> postgres: 0.88 sec
> ms-sql: 0.38 sec
>
> 200.000 from 50.000.000:
>
> postgres: 1.57 sec
> ms-sql: 0.54 sec
>
> 500.000 from 50.000.000:
>
> postgres: 3.66 sec
> ms-sql: 1.18 sec
Questions:
1. Is this the time to return *all rows* or just the first row? G
21 matches
Mail list logo
