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, Po
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 perfo
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_seqsc
the next transaction.
In essence, the backend would be "polling" itself every second or so
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
ably give 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
specific situation, my opinion is that the proper
modification to PostgreSQL would be to give it (if it isn't already
there) the ability to include the cost of functions in the plan. The
cost needn't be something that it automatically measures -- it could
be specified at function
#x27;t get used, then I had a similar issue with 8.0.3 where an
> index that was mergejoinable (only because of the restrictions in the
> where clause) wasn't getting picked up.
The following is already there:
CREATE INDEX ordered_product_id_index
ON to_ship
USING btree
(ordered_pro
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 ind
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 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 sec
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 en
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 in
cations 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)--
the *first*
> block, as opposed to Postgres which reports the time required to return the
> whole dataset.
Interesting. I had no idea MSSQL did that, but I can't exactly say
I'm surprised. :-)
--
Kevin Brown [EMAIL PROTECTED]
---
ut have psql ignore the output?
> If so, you could use \timing.
Would timing "SELECT COUNT(*) FROM (query)" work?
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Rosser Schwarz wrote:
> while you weren't looking, Kevin Brown wrote:
>
> [reordering bursty reads]
>
> > In other words, it's a corner case that I strongly suspect
> > isn't typical in situations where SCSI has historically made a big
> > differen
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
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 i
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
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
t of view of the kernel).
The specification doesn't require that the kernel act on the calls
immediately or write only the blocks referred to by the call in
question.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)-
le volumes can cause head movement where the kernel
might be treating the volumes as completely independent. But that
just means that you 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 w
ity hasn't really been an issue, at least as far as
the basics go, I still agree 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
Greg Stark wrote:
>
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > Also, one has to ask what the consequences are of assuming a value too
> > low versus too high. Which ends up being worse?
>
> This is one of the things the planner really cannot know. Ultimatel
http://archives.postgresql.org/pgsql-hackers/2000-10/msg01108.php
> It never got done but that seems like the most reasonable solution to
> me.
Or keep some statistics on cursor usage, and adjust the value
dynamically based on actual cursor queries (this might be easier said
than d
tes a new row (it's the equivalent 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]
show up in the result set, as long as updates show up
(because the cache table is just 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]
-
e disk subsystem is likely to be a bottleneck long before the CPU is
in the general case, especially these days as disk subsystems haven't
improved in performance nearly as quickly as CPUs have.
--
Kevin Brown [EMAIL PROTECTED]
--
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 re
probably one of those optimizations that should
be done when there's little else 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, mu
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> mmap() is Right Out because it does not afford us sufficient control
> >> over when changes to the in-memory data will propagate to disk.
>
> > ... that's especi
data/index pages in the face of a rock-solid
WAL).
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > This is why I sometimes wonder whether or not it would be a win to use
> > mmap() to access the data and index files --
>
> mmap() is Right Out because it does not afford us sufficient control
> over when
ace. I
suspect issues like this have already been worked out by others,
however...
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
using JFS.
I'll run the test program and report 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 broad
imal than doing nothing. The only question, of course,
is whether or not it's worth 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
being performed).
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
would be more efficient.
The auto vacuum daemon helps in this regard, by keeping the statistics
more up-to-date.
Certainly you shouldn't go overboard by setting random_page_cost too low
"just in case", but it does mean that if you go through the process of
running te
hat scans the entire filesystem and
stores all the inode information 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
t I don't know that you'll get much different results than your
version.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
40 matches
Mail list logo
