My experience has been that the performance advantage for numeric keys is
primarily an Oracle thing. However, Oracle is popular enough for people to
assume that it applies to databases in general.
Julien Cigar wrote:
>The biggest difference in performance between text and integer keys is
>us
Yes. And this has little to do with hints. It has to do with years
of development lead with THOUSANDS of engineers who can work on the
most esoteric corner cases in their spare time. Find the pg project a
couple hundred software engineers and maybe we'll catch Oracle a
little quicker. Otherw
On PostgreSQL, the difference in no hints and hints for that one query
with skewed data is that the query finishes a little faster. On some
others, which shall remain nameless, it is the difference between
finishing in seconds or days, or maybe never. Hints can be useful, but
I can also s
Instead of something like 'shake' (which more or less works, even
though it doesn't use fallocate and friends) I frequently use either
CLUSTER (which is what Greg Smith is suggesting) or a series of ALTER
TABLE ... ALTER COLUMN... which rewrites the table. With PG 9 perhaps
VACUUM FULL is more
Putting the WAL on a second controller does help, if you're write-heavy.
I tried separating indexes and data once on one server and didn't
really notice that it helped much. Managing the space was problematic.
I would suggest putting those together on a single RAID-10 of all the
300GB drives
>
> My guess is its something hypervisor related. If this happened on direct
> hardware I'd be more surprised. Hypervisors have all sorts of stuff going
> on, like throttling the number of CPU cycles a vm gets. In your idle
> case, your VM might effectively occupy 1Ghz of a CPU, but 2Ghz in the
>
> Odd. Did'ja by chance run the select more than once... maybe three or
> four times, and always get the same (or close) results?
>
> Is the stress package running niced?
>
> -Andy
>
I got a little crazy, and upgraded the DB to 8.4.5. It still reacts the
same.
I am hoping someone has an idea
> gr...@amadensor.com writes:
>> Here is the fun part. When running 8 threads spinning calculating
>> square
>> roots (using the stress package), the full scan returned consistently
>> 60%
>> faster than the machine with no load.
>
> Possibly the synchronized-seqscans logic kicking in, resulting
>
> Odd. Did'ja by chance run the select more than once... maybe three or
> four times, and always get the same (or close) results?
>
> Is the stress package running niced?
>
The stress package is not running niced. I ran it initially 5 times each.
It was very consistent. Initially, I just ran
I was doing a little testing to see how machine load affected the
performance of different types of queries, index range scans, hash joins,
full scans, a mix, etc.
In order to do this, I isolated different performance hits, spinning only
CPU, loading the disk to create high I/O wait states, and us
Hi Hi all,
I have now readed many many forums and tried many different solutions and I
am not getting good performance to database. My server is Debian linux, with
4gb ram, there is also java application and I am giving to that 512mb
(JAVA_OPTS) memory. In database there is now like 4milj rows. Wh
11 matches
Mail list logo
