[EMAIL PROTECTED] (Stuart Bishop) writes:
> I'm putting together a road map on how our systems can scale as our
> load increases. As part of this, I need to look into setting up some
> fast read only mirrors of our database. We should have more than
> enough RAM to fit everything into memory. I wou
Stuart Bishop wrote:
I'm putting together a road map on how our systems can scale as our load
increases. As part of this, I need to look into setting up some fast read
only mirrors of our database. We should have more than enough RAM to fit
everything into memory. I would like to find out if I co
I'm putting together a road map on how our systems can scale as our load
increases. As part of this, I need to look into setting up some fast read
only mirrors of our database. We should have more than enough RAM to fit
everything into memory. I would like to find out if I could expect better
perf
Madison,
> The problem comes when the user toggles a directory branch's backup
> flag (a simple check box beside the directory name). If it's a directory
> near the end of a branch it is fast enough. If they toggle a single file
> it is nearly instant. However if they toggle say the root direct
This is the kicker right there; my program is released under the GPL
so it's fee-free. I can't eat anything costly like that. As it is there
is hundreds and hundreds of hours in this program that I am already
hoping to recoup one day through support contracts. Adding commercial
softwa
PFC wrote:
Hello,
I once upon a time worked in a company doing backup software and I
remember these problems, we had exactly the same !
Prety neat. :)
The file tree was all into memory and everytime the user clicked on
something it haaad to update everything. Being C++ it wa
Hello,
I once upon a time worked in a company doing backup software and I
remember these problems, we had exactly the same !
The file tree was all into memory and everytime the user clicked on
something it haaad to update everything. Being C++ it was very fast, but
to backup a mil
Thanks!
That took care of it.
On Jul 7, 2005, at 4:02 PM, Tom Lane wrote:
Bendik Rognlien Johansen <[EMAIL PROTECTED]> writes:
I am running few of these deletes (could become many more) inside a
transaction and each one takes allmost a second to complete.
Is it because of the foreign key const
Jean-Max Reymond wrote:
On 7/7/05, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Do you have the same locale settings on all of them?
interressant:
UNICODE on the fast laptop
SQL_ASCII on the slowest desktops.
is UNICODE database faster than SQL_ASCII ?
That's your encoding (character-set).
On 7/7/05, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>
> Do you have the same locale settings on all of them?
>
interressant:
UNICODE on the fast laptop
SQL_ASCII on the slowest desktops.
is UNICODE database faster than SQL_ASCII ?
--
Jean-Max Reymond
CKR Solutions Open Source
Nice France
htt
On Thu, Jul 07, 2005 at 02:49:05PM +0200, Jean-Max Reymond wrote:
> Hi,
> These last two days, I have some troubles with a very strange phenomena:
> I have a 400 Mb database and a stored procedure written in perl which
> call 14 millions times spi_exec_query (thanks to Tom to fix the memory
> leak
Bendik Rognlien Johansen <[EMAIL PROTECTED]> writes:
> I am running few of these deletes (could become many more) inside a
> transaction and each one takes allmost a second to complete.
> Is it because of the foreign key constraint, or is it something else?
You need an index on "original" to sup
Niccolo Rigacci <[EMAIL PROTECTED]> writes:
> How can I EXPLAIN ANALYZE a cursor like this?
> BEGIN;
> DECLARE mycursor BINARY CURSOR FOR
> SELECT ...
> FETCH ALL IN mycursor;
> END;
> I tried to put EXPLAIN ANALYZE in front of the SELECT and in
> front of the FETCH, but I got two "s
On Thu, Jul 07, 2005 at 03:48:06PM +0200, Dawid Kuroczko wrote:
> This is why AMD stopped giving GHz ratings and instead uses numbers
> which indicate how their processor relate to Pentium 4s. For instance
> AMD Athlon XP 1700+ is running at 1.45 GHz, but competes with
> Pentium 4 1.7 GHz.
Actual
On 7/7/05, Jean-Max Reymond <[EMAIL PROTECTED]> wrote:
> On my laptop whith Centrino 1.6 GHz, 512 Mb RAM,
> - it is solved in 1h50' for Linux 2.6
> - it is solved in 1h37' for WXP Professionnal ( WXP better
> tan Linux ;-) )
[...]
> I test CPU, memory performance on my laptop and it seems that the
Hi all,
I hope I am not asking too many questions. :)
I have been trying to solve a performance problem in my program for a
while now and, after getting an index to work which didn't speed things
up enough, I am stumped. I am hoping someone here might have come across
a similar issue and
So, it seems that for my application (database in memory, 14 millions
of very small requests), Centrino (aka Pentium M) has a build-in
hardware to boost Postgres performance :-)
Any experience to confirm this fact ?
On my Centrino, Python flies. This might be due to the very large
processor
On Thu, 07 Jul 2005 13:16:30 +0200, Bendik Rognlien Johansen
<[EMAIL PROTECTED]> wrote:
Hello,
I was wondering if there is any way to speed up deletes on this table
(see details below)?
I am running few of these deletes (could become many more) inside a
transaction and each one takes allmo
Hi,
These last two days, I have some troubles with a very strange phenomena:
I have a 400 Mb database and a stored procedure written in perl which
call 14 millions times spi_exec_query (thanks to Tom to fix the memory
leak ;-) ).
On my laptop whith Centrino 1.6 GHz, 512 Mb RAM,
- it is solved in 1h
Hi,
These last two days, I have some troubles with a very strange phenomena:
I have a 400 Mb database and a stored procedure written in perl which
call 14 millions times spi_exec_query (thanks to Tom to fix the memory
leak ;-) ).
On my laptop whith Centrino 1.6 GHz, 512 Mb RAM,
- it is solved in 1
Hello,
I was wondering if there is any way to speed up deletes on this table
(see details below)?
I am running few of these deletes (could become many more) inside a
transaction and each one takes allmost a second to complete.
Is it because of the foreign key constraint, or is it something el
On Thu, Jul 07, 2005 at 10:14:50AM +0100, Richard Huxton wrote:
> >By trial and error I discovered that adding an "ORDER BY
> >toponimo" clause to the SELECT, boosts the CURSOR performances
> >so that they are now equiparable to the SELECT alone.
> I think you're misunderstanding exactly what's
Niccolo Rigacci wrote:
I get the results in about 108 seconds (8060 rows).
If I issue the SELECT alone (without the CURSOR) I get the
same results in less than 1 second.
By trial and error I discovered that adding an "ORDER BY
toponimo" clause to the SELECT, boosts the CURSOR performances
On Wed, Jul 06, 2005 at 11:19:46PM +0200, Niccolo Rigacci wrote:
>
> I have a performace problem with the following query:
>
> BEGIN;
> DECLARE mycursor BINARY CURSOR FOR
> SELECT
> toponimo,
> wpt
> FROM wpt_comuni_view
> WHERE (
> wpt &&
> s
> >Can the CURSOR on JOIN affects so heavly the WHERE clause? I
> >suspect that - with the CURSOR - a sequential scan is performed
> >on the entire data set for each fetched record...
> >
> >Any idea?
> >
> >
> What does it say if you do "EXPLAIN ANALYZE SELECT..." both with and
> without the curso
25 matches
Mail list logo
