Re: [PERFORM] Different execution plan

[Sabin Coanda]

Hi Scott,

I think it would be nice to log the reasons why an explain analyze chooses a 
specific way or another for an execution plan. This would avoid wasting time 
to find the source of these decisions from the existing logs.

Is it possible ?

TIA,
Sabin 



-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Different execution plan

[Sabin Coanda]

I use postgresql-8.2-506.jdbc3.jar, maybe helps

Sabin 



-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

[PERFORM] UFS 2: soft updates vs. gjournal (AKA: Choosing a filesystem 2.)

[Laszlo Nagy]

Hi again,

Should I use gjournal on FreeBSD 7? Or just soft updates?

Here is my opinion: I suspect that gjournal would be much slower than
soft updates. Also gjournal is relatively new code, not very well
tested. But gjournal is better when the system crashes. Although I have
heard that sometimes gjournal will crash the system itself. There are
more pros for soft updates I would pefer that. But please let me
know if I'm wrong.

Thanks,

  Laszlo






--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] UFS 2: soft updates vs. gjournal (AKA: Choosing a filesystem 2.)

[Claus Guttesen]

> Should I use gjournal on FreeBSD 7? Or just soft updates?
>
> Here is my opinion: I suspect that gjournal would be much slower than
> soft updates. Also gjournal is relatively new code, not very well
> tested. But gjournal is better when the system crashes. Although I have
> heard that sometimes gjournal will crash the system itself. There are
> more pros for soft updates I would pefer that. But please let me
> know if I'm wrong.

If softupdates suites your needs why not just use that? :-) Is
performance adequate with softupdates? I have a 103 GB db on FreeBSD
7.0 and softupdates and it has survived one unplanned stop when we had
a power-outage lasting some hours.

-- 
regards
Claus

When lenity and cruelty play for a kingdom,
the gentler gamester is the soonest winner.

Shakespeare

-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] UFS 2: soft updates vs. gjournal (AKA: Choosing a filesystem 2.)

[Artis Caune]

On Wed, Sep 24, 2008 at 1:18 PM, Laszlo Nagy <[EMAIL PROTECTED]> wrote:
> Here is my opinion: I suspect that gjournal would be much slower than
> soft updates. Also gjournal is relatively new code, not very well
> tested.

In some cases it's much faster than SU, in other a bit slower. :)
gjournal is quiet "old" code, it's already more than two years around,
and very stable. Haven't seen any gjournal related crash.





-- 
regards,
Artis Caune

<. CCNA
<|
<' didii FreeBSD

-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Different execution plan

[Matthew Wakeling]

On Wed, 24 Sep 2008, Sabin Coanda wrote:

I think it would be nice to log the reasons why an explain analyze chooses a
specific way or another for an execution plan. This would avoid wasting time
to find the source of these decisions from the existing logs.


That would probably fill up the logs pretty quickly.

What may be really useful would be some sort of "extended explain" option. 
At the moment, explain prints out the best query plan found. Sometimes it 
would be nice if it printed out all the plans it considered, so we don't 
have to go fiddling with enable_xxx to find alternatives.


Matthew

--
I suppose some of you have done a Continuous Maths course. Yes? Continuous
Maths?  Whoah, it was like that, was it!
   -- Computer Science Lecturer

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Intel's X25-M SSD

[Steve Clark]

Scott Carey wrote:

A fantastic review on this issue appeared in July:
http://www.alternativerecursion.info/?p=106
And then the same tests on a RiData SSD show that they are the same 
drive with the same characteristics:

http://www.alternativerecursion.info/?p=276

Most blamed it on MLC being "slow" to write compared to SLC.  
Technically, it is slower, but not by a whole lot -- we're talking a low 
level difference of tens of microseconds.  A 250ms latency indicates an 
issue with the controller chip.  SLC and MLC share similar overall 
performance characteristics at the millisecond level.  The truth is that 
MLC designs were low cost designs without a lot of investment in the 
controller chip.  The SLC designs were higher cost designs that focused 
early on on making smarter and more expensive controllers.  SLC will 
always have an advantage, but it isn't going to be by several orders of 
magnitude like it was before Intel's drive appeared.  Its going to be by 
factors of ~2 to 4 on random writes in the long run.  However, for all 
flash based SSD devices, there are design tradeoffs to make.  Maximizing 
writes sacrifices reads, maximizing random access performance reduces 
streaming performance and capacity.  We'll have a variety of devices 
with varying characteristics optimal for different tasks.


On Tue, Sep 23, 2008 at 8:24 PM, Bruce Momjian <[EMAIL PROTECTED] 
> wrote:


Greg Smith wrote:
 > On Mon, 8 Sep 2008, Merlin Moncure wrote:
 >
 > > What's interesting about the X25 is that they managed to pull the
 > > numbers they got out of a MLC flash product.  They managed this
with a
 > > DRAM buffer and the custom controller.
 >
 > I finally found a good analysis of what's wrong with most of the
cheap MLC
 > drives:
 >
 >
http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3403&p=7

 >
 > 240ms random write latency...wow, no wonder I keep hearing so
many reports
 > of cheap SSD just performing miserably.  JMicron is one of those
companies
 > I really avoid, never seen a design from them that wasn't cheap junk.
 > Shame their awful part is in so many of the MLC flash products.

I am surprised it too so long to identify the problem.

--
 Bruce Momjian  <[EMAIL PROTECTED] >  
 http://momjian.us

 EnterpriseDB http://enterprisedb.com

 + If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-performance mailing list
(pgsql-performance@postgresql.org
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance



Anybody know of any tests on systems that have specific filesystems for
flash devices?


--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] UFS 2: soft updates vs. gjournal (AKA: Choosing a filesystem 2.)

[Axel Rau]

Am 24.09.2008 um 12:18 schrieb Laszlo Nagy:


Should I use gjournal on FreeBSD 7? Or just soft updates?

I'm using gjournal for 5 weeks now on my production server.
There are 4 journaled filesystems on a raid controller with
BBU. pg uses 23GB out of 1.6TB. I can't see any performance impact or  
other issue.
Recovery from an unclean shutdown took less than a minute as compared  
to half an hour with ufs2/softupdates/fsck.
However I'm still unsure if I should enable async mounts of rhe fs  
with tablespaces/WAL.

Anybody giving me advice?

Axel
--- ar3


--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] query planner and scanning methods

[Richard Broersma]

On Tue, Sep 23, 2008 at 3:57 PM, Richard Broersma
<[EMAIL PROTECTED]> wrote:
> SELECT A."dimension_book"."call", SUM( B."dimension_book"."call" ) AS
> OrderedRowNbr
> FROM ( your_above_query_without_the_limits ) AS A
> INNER JOIN ( your_above_query_without_the_limits ) AS B
> ON A."dimension_book"."call" >= B."dimension_book"."call"
> ORDER BY A."dimension_book"."call"
> HAVING SUM( A."dimension_book"."call" ) % 10 = 0;

Oops I just noticed that I used sum() where count() should be used and
that I forgot to include the group by clause.  Other than that, I hope
the suggestion was at least halfway helpful.

-- 
Regards,
Richard Broersma Jr.

Visit the Los Angeles PostgreSQL Users Group (LAPUG)
http://pugs.postgresql.org/lapug

-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance