On Thu, 2004-02-05 at 00:32, Christopher Browne wrote:
> > Things of note that might matter: the machine is a dual Opteron
> > 1.4GHz running Fedora Core 1 Test 1 for X86_64. The 7.3.4 was from
> > the Fedora distro and the 7.4.1 was the PGDG package. The database
> > is 3.5 Gigs with 10 millions
> I did some heavy-transaction-oriented tests recently on somewhat
> heftier quad-Xeon hardware, and found little difference between 2.4
> and 2.6, and a small-but-quite-repeatable advantage with FreeBSD 4.9.
> Now, I'm quite sure my load was rather different from yours, but I
> find the claim of d
Hi All,
I've been seeing very slow read performance on a database of 1 million
indexed subscribers, which I believe is nothing to do with the data
itself, but delays on processing the index.
If I make a random jump into the index (say X), it can take about 50ms
to read the subscriber. If I then
In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] ("Carlos
Eduardo Smanioto") transmitted:
>> I did some heavy-transaction-oriented tests recently on somewhat
>> heftier quad-Xeon hardware, and found little difference between 2.4
>> and 2.6, and a small-but-quite-repeatable a
Josh Berkus <[EMAIL PROTECTED]> writes:
> I'm wondering if we need specific compile-time switches for Opteron. I know
> we got Opteron code tweaks in the last version,
Not in 7.4. There is some marginal hacking in the spinlock code in CVS
tip for multi-CPU i386 and x86_64 (viz, add a PAUSE inst
On Thursday 05 February 2004 12:13, Damien Dougan wrote:
> Hi All,
>
> I've been seeing very slow read performance on a database of 1 million
> indexed subscribers, which I believe is nothing to do with the data
> itself, but delays on processing the index.
>
> If I make a random jump into the inde
Thanks Richard.
It certainly does appear to be memory related (on a smaller data set of
250K subscribers, all accesses are < 1ms).
We're going to play with increasing RAM on the machine, and applying the
optimisation levels on the page you recommended.
(We're also running on a hardware RAID con
Corey Edwards wrote:
Your column is a bigint but 123 defaults to type int. Indexes aren't
used when there's a type mismatch. Use an explicit cast or quote it:
select * from bigtable where id = 123::bigint;
Or
select * from bigtable where id = '123';
Thanks Corey, both of these do exactly wha
>
> One question though... It sounds like your 7.3 binaries are 64-bit and
> your 7.4 binaries are 32-bit. Have you tried grabbing the SRPM for 7.4
> and recompiling it for X86_64?
No, they were all 64 bit.
I'm going to run explains on all my queries and see if I can find
anything of interes
Damian,
Also, if there have been a lot of updates to the table, you may need to run a
REINDEX on it. An attenuated index would be slow to load because of the
nummber of empty disk blocks.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast
Jan Wieck wrote:
It might not work with the words I used above, but the point I tried to
make is that the hardest thing you can "sell" is a "no". I mean, not
just saying "no", but selling it in a way that the customer will not go
with the next idiot who claims "we can do that".
But you will need
Hi,
I have a quick question. In order to speed up insertion of large number of
rows (100s of thousands) I replaced the INSERT with the COPY. This works
fine but one question popped into my mind. Does copy updates indexes on
that table if there are some defined?
Thanks,
Slavisa
I have a quick question. In order to speed up insertion of large number of
rows (100s of thousands) I replaced the INSERT with the COPY. This works
fine but one question popped into my mind. Does copy updates indexes on
that table if there are some defined?
Yes, of course. Runs triggers and stuff
Thanks for the reply and thanks even more for the good one :).
Cheers,
Slavisa
On Fri, 6 Feb 2004, Christopher Kings-Lynne wrote:
> > I have a quick question. In order to speed up insertion of large number of
> > rows (100s of thousands) I replaced the INSERT with the COPY. This works
> > fine b
14 matches
Mail list logo
