On Saturday 04 March 2006 08:23, hubert depesz lubaczewski wrote:
On 3/4/06, Joost Kraaijeveld [EMAIL PROTECTED] wrote:
how many record do you have in the customers table?
368915 of which 222465 actually meet the condition.
From what I understand from the mailing list, PostgreSQL
On Wednesday 21 December 2005 20:14, Stephen Frost wrote:
* Madison Kelly ([EMAIL PROTECTED]) wrote:
If the performace difference comes from the 'COPY...' command being
slower because of the automatic quoting can I somehow tell PostgreSQL
that the data is pre-quoted? Could the performance
creation time.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
the user greater
incentive to report the problem than use of planner hints.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: explain analyze is your friend
and recording its state at that time, rather than on every
transaction.
Assuming that doing all that wouldn't screw something else up...
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Have you
Craig A. James wrote:
Kevin Brown wrote:
Hints are dangerous, and I consider them a last resort.
If you consider them a last resort, then why do you consider them to
be a better alternative than a workaround such as turning off
enable_seqscan, when all the other tradeoffs are considered
I'll just start by warning that I'm new-ish to postgresql.
I'm running 8.1 installed from source on a Debian Sarge server. I have a
simple query that I believe I've placed the indexes correctly for, and I
still end up with a seq scan. It makes sense, kinda, but it should be able
to use the
On Wednesday 14 December 2005 16:47, you wrote:
Kevin Brown [EMAIL PROTECTED] writes:
I'm running 8.1 installed from source on a Debian Sarge server. I have a
simple query that I believe I've placed the indexes correctly for, and I
still end up with a seq scan. It makes sense, kinda
On Wednesday 14 December 2005 17:23, you wrote:
what hardware?
Via 800 mhz (about equiv to a 300 mhz pentium 2)
128 mb of slow ram
4200 rpm ide hard drive.
Told you it was slow. :-)
This is not the production system. I don't expect this to be fast but
everything else happens in under 2
On Wednesday 14 December 2005 17:30, Mark Kirkwood wrote:
You scan 60 rows from to_ship to get about 25000 - so some way to
cut this down would help.
Yup. I'm open to anything too, as this is the only real part of the system
that cares. So either maintaining a denormalized copy column,
On Wednesday 14 December 2005 18:36, you wrote:
Well - that had no effect at all :-) You don't have and index on
to_ship.ordered_product_id do you? - try adding one (ANALYZE again), and
let use know what happens (you may want to play with SET
enable_seqscan=off as well).
I _DO_ have an index
on the disk should remain the same, as should their data
blocks (roughly, depending on the implementation of the filesystem, of
course).
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: Don't 'kill
that, but I can't exactly say
I'm surprised. :-)
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command
Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
In the case of pure random reads, you'll end up having to wait an
average of half of a rotation before beginning the read.
You're assuming the conclusion. The above is true if the disk is handed
one request at a time by a kernel
Vivek Khera wrote:
On Apr 14, 2005, at 10:03 PM, Kevin Brown wrote:
Now, bad block remapping destroys that guarantee, but unless you've
got a LOT of bad blocks, it shouldn't destroy your performance, right?
ALL disks have bad blocks, even when you receive them. you honestly
think
can't be dumb about how you configure your RAID
setup.
So what gives? Given the above, why is SCSI so much more efficient
than plain, dumb SATA? And why wouldn't you be much better off with a
set of dumb controllers in conjunction with (kernel-level) software
RAID?
--
Kevin Brown
in
question.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
I really don't see how this is any different between a system that has
tagged queueing to the disks and one that doesn't. The only
difference is where the queueing happens. In the case of SCSI, the
queueing happens on the disks
Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
Tom Lane wrote:
The reason this is so much more of a win than it was when ATA was
designed is that in modern drives the kernel has very little clue about
the physical geometry of the disk. Variable-size tracks, bad-block
sparing
with your general sentiment -- stay away
from the Dells, at least if they have the Perc3/Di controller. You'll
probably get much better performance out of something else.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast
of doing an insert
then a delete), all indexes have to be updated to reflect the location
of the new row.
Unless my understanding of how this works is completely off...
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast
a fancy index) and deletes work
(because the join against the data table will show only rows that are
common between both).
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 7: don't forget
, especially these days as disk subsystems haven't
improved in performance nearly as quickly as CPUs have.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 8: explain analyze is your friend
Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
Hmm...something just occurred to me about this.
Would a hybrid approach be possible? That is, use mmap() to handle
reads, and use write() to handle writes?
Nope. Have you read the specs regarding mmap-vs-stdio synchronization
left to optimize, because the
potential gains are possibly (if not probably) relatively small and
the amount of work involved may be quite large.
So I agree -- compared with other, much lower-hanging fruit, mmap()
doesn't look promising.
--
Kevin Brown
WAL).
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
my results with it as well, so
we'll be able to see if there's any consistency between it and the live
database.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 9: the planner will ignore
going to the effort when it may or may not
gain you a whole lot. Answering that is going to require some
experimentation with such an automatic configuration system.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast
tests to determine the proper value for random_page_cost, you
should probably select a random_page_cost that's in the lower part of
the range of values you got.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast
performed).
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
about every file in a newly-created table,
then merges it into the existing file information table. Each table
is about 2.5 million rows...
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 6
could try:
UPDATE requests
SET session = NULL
WHERE EXISTS
(
SELECT r.session
FROM requests r
WHERE
r.session = session
GROUP BY r.session
HAVING count(*) = 1
);
but I don't know that you'll get much different results than your
version.
--
Kevin Brown
32 matches
Mail list logo
