This is a well-worn thread title - apologies, but these results seemed
interesting, and hopefully useful in the quest to get better performance
on Solaris:
I was curious to see if the rather uninspiring pgbench performance
obtained from a Sun 280R (see General: ATA Disks and RAID controllers
f
Hello,
Today I met a very strange query problem, which I
spend several hours on it but have no clue. To make
thing clear, let me write somewhat in detail.
I have two almost exactly same queries, except that
one is: lower(annotation) = lower (chip), another
is: annotation = chip. While the first o
xfs_freeze is a userspace program included in the xfsprogs rpm. It does run
on Redhat 7.3 (the SGI supplied kernels and userspace for RedHat 7.3 are
somewhat dated; I'd suggest patching the 2.4.21 kernel with XFS 1.3.1
patches and upgrading the userspace programs from the SRPMS). Post to the
linux-
has anyone else noticed a huge difference in "DELETE TABLE "
vs. "TRUNCATE " starting w/postgres 7.4?
putting aside details (num rows, indexes): ca. 300 tables
(already empty if desired...) ALL to be emptied (via batch file).
here's a small "time pgsql -f kill_all" output:
DELETE:
1) 0.03u 0.0
I am using Asynchronous Query Processing interface from libpq library.
And I got some strange results on Solaris
My test select query is 'SELECT * from pg_user;'
and I use select system synchronous I/O multiplexer in 'C'
The first test sends 1 select queries using 10 nonblocking connections
t
Hello!
I am relative newcomer to SQL and PostgreSQL world, so please forgive me
if this question is stupid.
I am experiencing strange behaviour, where simple UPDATE of one field is
very slow, compared to INSERT into table with multiple indexes. I have
two tables - one with raw data records (about
Jack,
> Right, because re-architecture of a cross-platform query makes sense if
> performance is bad on all systems, but is questionable activity when
> performance is fine on some systems and lousy on others. Hence my
> statement that while SQL optimization is certainly something we want to
> do
> I ended up going back to a default postgresql.conf and reapplying the
> various tunings one-by-one. Turns out that while setting fsync = false
> had little effect on the slow IDE box, it had a drastic effect on this
> faster SCSI box and performance is quite acceptable now (aside from the
> expec
On Mon, 2003-12-08 at 11:19, Tom Lane wrote:
> Jack Coates <[EMAIL PROTECTED]> writes:
> > Theories at this point, in no particular order:
>
> > a) major differences between my 7.3.4 from source (compiled with no
> > options) and dev's 7.3.2-1PGDG RPMs. Looking at the spec file doesn't
> > reveal
stephen farrell <[EMAIL PROTECTED]> writes:
> With the indexes created it worked. It took about 4 hours, but it
> inserted all of the records.
Has this been satisfactorily resolved?
If not, can you post an EXPLAIN ANALYZE for the failing query, as Tom
asked earlier?
-Neil
10 matches
Mail list logo
