"Greg Stark" <[EMAIL PROTECTED]> wrote
>
> If the whole database is in RAM I wouldn't expect clustering to have any
> effect. Either you're doing a lot of merge joins or a few other cases
> where
> clustering might be helping you, or the cluster is helping you keep more
> of
> the database in ra
On Thu, 22 Dec 2005, Juan Casero wrote:
Ok thanks. I think I will go with 64 bit everything on the box. If I can get
the Sun Fire V20Z then I will stick with Solaris 10 x86 and download the 64
bit PostgreSQL 8.1 binaries from blastwave.org. I develop the PHP code to
my DSS system on my Windo
Ok thanks. I think I will go with 64 bit everything on the box. If I can get
the Sun Fire V20Z then I will stick with Solaris 10 x86 and download the 64
bit PostgreSQL 8.1 binaries from blastwave.org. I develop the PHP code to
my DSS system on my Windows XP laptop. Normally, I test the code
Harry Jackson <[EMAIL PROTECTED]> writes:
> At the moment everything is working OK but I am noticing an almost
> linear increase in time to retrieve data from the database as the data
> set increases in size. Clustering knocks the access times down by 25%
> but it also knocks users off the website
On Wed, 21 Dec 2005, Juan Casero wrote:
Date: Wed, 21 Dec 2005 22:31:54 -0500
From: Juan Casero <[EMAIL PROTECTED]>
To: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] What's the best hardver for PostgreSQL 8.1?
Sorry folks. I had a couple of glasses of wine as I wrote this. Anyway I
Agreed. I have a 13 million row table that gets a 100,000 new records every
week. There are six indexes on this table. Right about the time when it
reached the 10 million row mark updating the table with new records started
to take many hours if I left the indexes in place during the update
Sorry folks. I had a couple of glasses of wine as I wrote this. Anyway I
originally wanted the box to have more than two drives so I could do RAID 5
but that is going to cost too much. Also, contrary to my statement below it
seems to me I should run the 32 bit postgresql server on the 64 bit
Jan Dittmer <[EMAIL PROTECTED]> escreveu: What is your work_mem setting? I think the default is 1MB which isprobably too low as your trying to sort roughly 15*100Bytes = 15MB.Jan I think you would like to say 15*896Bytes... Am I right? My default work_mem is 2048 and I changed to 20..
Is there a reason you can't rewrite your SELECT like:
SELECT UUID FROM MDM.KEYWORDS_INFO WHERE KEYWORDS_ID IN (a, b, c, d)
Even doing them 100 at a time will make a big difference; you should
put as many in the list as pgsql supports. I'm assuming that there's
an index over KEYWORDS_ID.
Re
The problem is you are getting the entire list back at once.
You may want to try using a cursor.
Dave
On 15-Dec-05, at 9:44 AM, [EMAIL PROTECTED] wrote:
Hi,
I have a java.util.List of values (1) which i wanted to use for
a query in the where clause of an simple select statement.
iterat
I´m not sure but I think the extra runtime of the select statement that has the ORDER BY clause is because the planner decided to sort the result set. Is the sort really necessary? Why not only scanning the primary key index pages and retrieving the rows like the select without the order by cla
Hi, Madison,
Hi, Luke,
Luke Lonergan wrote:
> Note that indexes will also slow down loading.
For large loading bunches, it often makes sense to temporarily drop the
indices before the load, and recreate them afterwards, at least, if you
don't have normal users accessing the database concurrently
Tom Lane wrote:
> I'd expect plpgsql to suck at purely computational tasks, compared to
> the other PLs, but to win at tasks involving database access. These
There you go...pl/pgsql is pretty much required learning (it's not
hard). For classic data processing tasks, it is without peer. I would
Dear Tom,
On 2005.12.21. 20:34, Tom Lane wrote:
=?ISO-8859-2?Q?Sz=FBcs_G=E1bor?= <[EMAIL PROTECTED]> writes:
Query is:
SELECT idopont WHERE muvelet = x ORDER BY idopont LIMIT 1.
Much the best solution for this would be to have an index on
(muvelet, idopont)
--- perhaps you can reorder
Harry Jackson wrote:
I am currently using a dual Opteron (248) single core system (RAM
PC3200) and for a change I am finding that the bottleneck is not disk
I/O but CPU/RAM (not sure which).
Well that's the first thing to find out. What is "top" showing for CPU
usage and which processes?
--
15 matches
Mail list logo
