headers
Tom Lane | 1 Sep 2003 01:12
Picon

Re: How to force Nested Loop plan?

Rob Nagler <nagler <at> bivio.biz> writes:
> Are there plans for explicit hints to the planner?

Personally, I'm philosophically opposed to planner hints; see previous
discussions in the archives.

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

               http://archives.postgresql.org
Permalink | Reply | 2 comments |
headers
F Brown | 1 Sep 2003 03:45
Picon

Mail Test

------------
------------
------------
------------
------------
fred.brown <at> maps.lss.bc.ca
wilf.tannenbaum <at> maps.lss.bc.ca
david.mathews <at> maps.lss.bc.ca

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match
Permalink | Reply | 0 comments |
headers
Alberto Caso | 1 Sep 2003 14:11

Re: SQL performance problems

On Mon, 01-09-2003 at 13:42, Rhaoni Chiu Pereira wrote: 
> I've done that but it didn't make much difference.
> Do you know some documentation on explain ? I don't understand the results..
> 

http://developer.postgresql.org/docs/postgres/sql-explain.html
http://developer.postgresql.org/docs/postgres/performance-tips.html

Also this list's archives (which can be found at
http://archives.postgresql.org/pgsql-performance/ ) are a good source
of info on the subject.

Best Regards,

--

-- 
Alberto Caso Palomino
Adaptia Soluciones Integrales
http://www.adaptia.net
alberto.caso <at> adaptia.net
Permalink | Reply | 0 comments |
headers
Ron Johnson | 1 Sep 2003 17:22
Picon
Gravatar

Re: How to force Nested Loop plan?

On Sun, 2003-08-31 at 18:12, Tom Lane wrote:
> Rob Nagler <nagler <at> bivio.biz> writes:
> > Are there plans for explicit hints to the planner?
> 
> Personally, I'm philosophically opposed to planner hints; see previous
> discussions in the archives.

How about (if you don't already do it) ranked (or approximately 
ranked) b-tree indexes, where each node also stores the (approximate)
count of tuple pointers under it?

This way, the planner would know whether or how skewed a tree is,
and (approximately) how many tuples a given WHERE predicate resolves
to.

--

-- 
-----------------------------------------------------------------
Ron Johnson, Jr. ron.l.johnson <at> cox.net
Jefferson, LA USA

"Fair is where you take your cows to be judged."
Unknown

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

               http://archives.postgresql.org
Permalink | Reply | 1 comment |
headers
Tom Lane | 1 Sep 2003 23:03
Picon

Re: How to force Nested Loop plan?

Ron Johnson <ron.l.johnson <at> cox.net> writes:
> How about (if you don't already do it) ranked (or approximately 
> ranked) b-tree indexes, where each node also stores the (approximate)
> count of tuple pointers under it?
> This way, the planner would know whether or how skewed a tree is,
> and (approximately) how many tuples a given WHERE predicate resolves
> to.

Why is that better than our existing implementation of column statistics?

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
Permalink | Reply | 0 comments |
headers
Vivek Khera | 2 Sep 2003 18:01

Re: Hardware recommendations to scale to silly load

>>>>> "AS" == Andrew Sullivan <andrew <at> libertyrms.info> writes:

AS> On Fri, Aug 29, 2003 at 12:05:03AM -0700, William Yu wrote:
>> We should see a boost when we move to 64-bit Linux and hopefully another 
>> one when NUMA for Linux is production-stable.

AS> According to the people who've worked with SGIs, NUMA actually seems
AS> to make things worse.  It has something to do with how the shared
AS> memory is handled.  You'll want to dig through the -general or
AS> -hackers archives from somewhere between 9 and 14 months ago, IIRC.

I knew my PhD research would one day be good for *something* ...

The basic premise of NUMA is that you can isolate which data belongs
to which processor and put that on memory pages that are local/closer
to it.  In practice, this is harder than it sounds as it requires very
detailed knowledge of the application's data access patterns, and how
memory is allocated by the OS and standard libraries.  Often you end
up with pages that have data that should be local to two different
processors, and that data keeps being migrated (if your NUMA OS
supports page migration) between the two processors or one of them
just gets slow access.

I can't imagine it benefiting postgres given its globally shared
buffers.

--

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D.                Khera Communications, Inc.
Internet: khera <at> kciLink.com       Rockville, MD       +1-240-453-8497
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vivek Khera | 2 Sep 2003 18:08

Re: Hardware recommendations to scale to silly load

>>>>> "MC" == Matt Clark <matt <at> ymogen.net> writes:

MC> And concurrency is very high, because it's a web app, and each
MC> httpd has one connection to PG, and there can be hundreds of
MC> active httpd processes.  Some kind of connection pooling scheme
MC> might be in order when there are that many active clients.  Any

One thing you really should do (don't know if you already do it...) is
have your web split into a front-end proxy and a back-end application
server.  There are lots of docs on how to do this for mod_perl, but it
can apply to just about any backend technology that is pooling the
connections.

With a setup like this, my front-end web server typically has about
100 to 150 connections, and the backend doing the dynamic work (and
accessing the database) has peaked at 60 or so.  Usually the backend
numbers at about 25.

The front-end small processes get to deal with your dialup customers
trickling down the data since it buffers your backend for you.

--

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D.                Khera Communications, Inc.
Internet: khera <at> kciLink.com       Rockville, MD       +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera   http://www.khera.org/~vivek/

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo <at> postgresql.org
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Sullivan | 2 Sep 2003 18:14

Re: opinion on RAID choice

On Thu, Aug 28, 2003 at 03:26:14PM -0600, scott.marlowe wrote:
> 
> My experience has been that once you get past 6 disks, RAID5 is faster 
> than RAID1+0.

Also depends on your filesystem and volume manager.  As near as I can
tell, you do _not_ want to use RAID 5 with Veritas.

A

--

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew <at> libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
Permalink | Reply | 5 comments |
headers
Larry Rosenman | 2 Sep 2003 18:24
Gravatar

Re: opinion on RAID choice


--On Tuesday, September 02, 2003 12:14:34 -0400 Andrew Sullivan 
<andrew <at> libertyrms.info> wrote:

> On Thu, Aug 28, 2003 at 03:26:14PM -0600, scott.marlowe wrote:
>>
>> My experience has been that once you get past 6 disks, RAID5 is faster
>> than RAID1+0.
>
> Also depends on your filesystem and volume manager.  As near as I can
> tell, you do _not_ want to use RAID 5 with Veritas.
Out of curiosity, why?

I have Veritas Doc up (since UnixWare has it) at:

http://www.lerctr.org:8458/en/Navpages/FShome.html

if anyone wants to read.

LER

>
> A

--

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler <at> lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

---------------------------(end of broadcast)---------------------------
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ron Johnson | 2 Sep 2003 18:33
Picon
Gravatar

Re: opinion on RAID choice

On Tue, 2003-09-02 at 11:14, Andrew Sullivan wrote:
> On Thu, Aug 28, 2003 at 03:26:14PM -0600, scott.marlowe wrote:
> > 
> > My experience has been that once you get past 6 disks, RAID5 is faster 
> > than RAID1+0.
> 
> Also depends on your filesystem and volume manager.  As near as I can
> tell, you do _not_ want to use RAID 5 with Veritas.

Why should Veritas care?  Or is it that Veritas has a high overhead
of small block writes?

--

-- 
-----------------------------------------------------------------
Ron Johnson, Jr. ron.l.johnson <at> cox.net
Jefferson, LA USA

"Millions of Chinese speak Chinese, and it's not hereditary..."
Dr. Dean Edell

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo <at> postgresql.org
Permalink | Reply | 2 comments |

Gmane