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
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
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
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
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
>
> 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
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
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
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
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
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
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
> 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
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
14 matches
Mail list logo
