Original query:
explain analyse select * from tracker where objectid 120;
QUERY PLAN
---
Index Scan using tracker_objectid on tracker
(cost=0.00..915152.62 rows=3684504 width=33)
With a 16 CPU, 32 GB Solaris Sparc server, is there any conceivable
reason to use a 32 bit build rather than a 64 bit build? Apparently the
Sun PostgreSQL package includes a README that indicates you might want
to think twice about using 64 bit because it is slower -- this seems
like outdated
Joseph Conway m...@joeconway.com writes:
Also semi-related question: when building from source, using gcc,
enabling debug (but *not* assert) is normally not much of a performance
hit. Is the same true if you build with the Sun CC?
Most non-gcc compilers disable optimization altogether if you
Excerpts from Matthew Wakeling's message of mar ago 10 11:40:16 -0400 2010:
I am trying to retrieve, for many sets of rows grouped on a couple of
fields, the value of an ungrouped field where the row has the highest
value in another ungrouped field.
I think this does what you want (schema
Greg Smith wrote:
* How to test for power failure?
I've had good results using one of the early programs used to
investigate this class of problems:
http://brad.livejournal.com/2116715.html?page=2
FYI, this tool is mentioned in the Postgres documentation:
On Aug 10, 2010, at 9:21 AM, Greg Smith wrote:
Scott Carey wrote:
Also, the amount of data at risk in a power loss varies between
drives. For Intel's drives, its a small chunk of data ( 256K). For
some other drives, the cache can be over 30MB of outstanding writes.
For some workloads
On Aug 10, 2010, at 11:28 AM, Greg Smith wrote:
Brad Nicholson wrote:
What about putting indexes on them? If the drive fails and drops
writes on those, they could be rebuilt - assuming your system can
function without the index(es) temporarily.
Dumping indexes on SSD is one of the
On Aug 10, 2010, at 11:38 AM, Karl Denninger wrote:
Scott Marlowe wrote:
On Tue, Aug 10, 2010 at 12:13 PM, Karl Denninger
k...@denninger.netmailto:k...@denninger.net wrote:
ANY disk that says write is complete when it really is not is entirely
unsuitable for ANY real database use. It is
Scott Carey wrote:
On Aug 10, 2010, at 11:38 AM, Karl Denninger wrote:
.
Most people who will do this won't reload it after a crash. They'll
inspect the database and say ok, and put it back online. Bad
Karma will ensue in the future.
Anyone going with something unconventional
A number of amusing aspects to this discussion.
- I've carried out similar tests using the Intel X-25M with both PG and DB2
(both on linux). While it is a simple matter to build parallel databases on
DB2, on HDD and SSD, with buffers and tablespaces and logging and on and on set
to recreate
Tom Lane wrote:
Hannu Krosing ha...@2ndquadrant.com writes:
Of course there are more variables than just *_page_cost, so if you nail
down any other one, you may end with less than 1 for both page costs.
I have always used seq_page_cost = 1 in my thinking and adjusted others
relative to
On Wed, Aug 11, 2010 at 9:42 PM, Bruce Momjian br...@momjian.us wrote:
This confused me. If we are assuing the data is in
effective_cache_size, why are we adding sequential/random page cost to
the query cost routines?
See the comments for index_pages_fetched(). We basically assume that
all
On Wed, Aug 4, 2010 at 1:16 AM, Heiko L. hei...@fh-lausitz.de wrote:
Hallo,
Im running pg-8,pgpoolII on sol10-zone.
I noticed late you mention 8.3.1. Two points, you're missing 1 year
of updates, bug fixes, security patches etc. Assuming this version
was fast before, we'll assume it's not
Scott Carey wrote:
What is the likelihood that your RAID card fails, or that the battery that
reported 'good health' only lasts 5 minutes and you lose data before power is
restored? What is the likelihood of human error?
These are all things that happen sometimes, sure. The problem
gnuo...@rcn.com wrote:
Sufficiently bulletproof flash SSD exist and have for years, but their names
are not well known (no one on this thread has named any)
The models perceived as bulletproof are the really dangerous ones to
deploy. First, people let their guard down and stop being as
15 matches
Mail list logo
