A long time ago, in a galaxy far, far away, "Bupp Phillips" <[EMAIL PROTECTED]> wrote:
>I have a table that has 103,000 records in it (record size is about
>953 bytes) and when I do a select all (select * from ) it takes
>a whopping 30 secs for the data to return!!
>SQLServer on the other hand ta
On Mon, 25 Aug 2003, Bupp Phillips wrote:
>
> I have a table that has 103,000 records in it (record size is about 953
> bytes) and when I do a select all (select * from ) it takes a
> whopping 30 secs for the data to return!!
>
> SQLServer on the other hand takes 6 secs, but you can also use what
Bupp Phillips <[EMAIL PROTECTED]> wrote:
> I'm very new to Postgresql, so don't beat me up to bad if you see a
> problem, just inform me what I've done wrong.
>
> I'm use Postgresql 7.2 (PeerDirect's Windows port) on Win2000 384MB
> RAM 10GB of Free space 800 Mhz, using the ODBC driver 7.03.01.00.
Stephan Szabo wrote:
Looking at the explain:
Veering aside a bit, since we usually pinpoint performance problems by
looking at EXPLAIN ANALYZE's differences between the planner's
estimation and actual execution's stats, what's involved in parsing the
EXPLAIN ANALYZE results, and highlighting th
On Tue, 26 Aug 2003, Ang Chin Han wrote:
> Stephan Szabo wrote:
>
> > Looking at the explain:
>
> Veering aside a bit, since we usually pinpoint performance problems by
> looking at EXPLAIN ANALYZE's differences between the planner's
> estimation and actual execution's stats, what's involved in pa
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Tue, 26 Aug 2003, Ang Chin Han wrote:
>> Veering aside a bit, since we usually pinpoint performance problems by
>> looking at EXPLAIN ANALYZE's differences between the planner's
>> estimation and actual execution's stats, what's involved in parsing the
need input on parameter values on confs...
our database is getting 1000 transactions/sec on peak periods..
sitting on RH 7.3
2.4.7-10smp
RAM: 1028400
SWAP: 2040244
queries are just simple select statements based on timestamps, varchars...
less on joins... on a 300K rows..
TIA
---
Here's an interesting situation, and I think it may be just that Sun
stinks.
I was recently given the go ahead to switch from Informix to Postgres on
one of our properties. (I had dozens of performance comparisons showing
how slow Informix was compared to it and my boss seeing me struggle trying
On Tuesday 26 August 2003 14:42, JM wrote:
> need input on parameter values on confs...
>
> our database is getting 1000 transactions/sec on peak periods..
>
> sitting on RH 7.3
> 2.4.7-10smp
> RAM: 1028400
> SWAP: 2040244
>
> queries are just simple select statements based on timestamps, varchars.
I spoke with my SUN admin, and this is what he had to say about what you are
seeing.
Sun gear is known to show a lower than Intel performance on light loads, rerun
your test with 100 concurrent users (queries) and see what happens. Also he
recommends installing a 64bit version of Solaris, the
Is this something that can be done thru a SQL statement, or are you saying
that I need to develop logic to handle this because the database won't hold
the resultset on the server, but instead sends it all to the client?
It there a way to get server side cursors with Postgresql like SQLServer has
o
Also, after having taken another look at this, you aren't preforming the same
query on both datasets, so you can't expect them to generate the same
results, or the same query plans, or even comparable times. Please retry your
tests with identical queries , specify the dates, don;t use a function
On Tue, Aug 26, 2003 at 02:18:23AM -0700, Bupp Phillips wrote:
> It there a way to get server side cursors with Postgresql like SQLServer has
> or is this a limitation that it has?
http://www.postgresql.org/docs/7.3/static/sql-declare.html
http://www.postgresql.org/docs/7.3/static/sql-fetch.html
On Tue, 26 Aug 2003, Darcy Buskermolen wrote:
> Also, after having taken another look at this, you aren't preforming the same
> query on both datasets, so you can't expect them to generate the same
> results, or the same query plans, or even comparable times. Please retry your
> tests with identic
I'm still seeing differences in the planner estimates, have you run a VACUUM
ANALYZE prior to running these tests?
Also, are the disk subsystems in these 2 systems the same? You may be seeing
some discrepancies in things spindle speed, U160 vs U320, throughput on
specific RAID controlers, diff
On Tue, 26 Aug 2003, Darcy Buskermolen wrote:
> I'm still seeing differences in the planner estimates, have you run a VACUUM
> ANALYZE prior to running these tests?
>
I did. I shall retry that.. but the numbers (the cost estimates) are
pretty close on both. the actual times are very different.
>
On Tue, Aug 26, 2003 at 03:05:12PM -0400, Jeff wrote:
> On Tue, 26 Aug 2003, Darcy Buskermolen wrote:
> > I'm still seeing differences in the planner estimates, have you run a VACUUM
> > ANALYZE prior to running these tests?
> >
> I did. I shall retry that.. but the numbers (the cost estimates) are
17 matches
Mail list logo
