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? Given the
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
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
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
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?
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 years. If
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
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
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
*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
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 SQL
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
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.
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
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
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 seconds.
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 case, as
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
18 matches
Mail list logo
