Re: [PERFORM] Question about CLUSTER

On Mon, Feb 11, 2008 at 03:33:37PM -0600, Scott Marlowe wrote: > On Feb 11, 2008 2:03 PM, salman <[EMAIL PROTECTED]> wrote: > > I'm planning to cluster a few large tables in our database but I'm > > unable to find any recommendations/documentation on best practices -- > > Mainly, whether it's bette

Re: [PERFORM] Questions about enabling SSL

On Mon, Feb 11, 2008 at 05:37:51PM -0700, Michael Fuhr wrote: > On Mon, Feb 11, 2008 at 04:58:35PM -0700, fabrix peñuelas wrote: > > If ssl is enable in postgresql decreanse the performance of the database? > > How much? > > The performance impact of an encrypted connection depends on how > expen

Re: [PERFORM] Questions about enabling SSL

On Mon, Feb 11, 2008 at 04:58:35PM -0700, fabrix peñuelas wrote: > If ssl is enable in postgresql decreanse the performance of the database? > How much? The performance impact of an encrypted connection depends on how expensive the queries are and how much data they return. A query that joins se

[PERFORM] Questions about enabling SSL

Hi all... If ssl is enable in postgresql decreanse the performance of the database? How much? Thanks in advance

Re: [PERFORM] mis-estimate in nested query causes slow runtimes

Chris Kratz <[EMAIL PROTECTED]> writes: > -> Nested Loop (cost=42.74..161.76 rows=1 width=38) (actual > time=2.932..27.772 rows=20153 loops=1) > -> Hash Join (cost=10.89..22.58 rows=1 width=24) (actual > time=0.065..0.134 rows=1 loops=1) > Hash Cond: (mtchsrcprj3.fun

[PERFORM] mis-estimate in nested query causes slow runtimes

Hello, I've been wrestling w/ a complex query for another developer for awhile today. The problem consistently seems to a mis-estimation of the number of rows resulting from a join. This causes the query early on to think it's only going to be processing 1 row and so it chooses nested l

Re: [PERFORM] Join Query Perfomance Issue

Correction: > turning off nested loops for that one. But don't turn off nested > queries universally, they are still a good choice for smaller amounts > of data. queries should be loops up there... ---(end of broadcast)--- TIP 1: if posting/readin

Re: [PERFORM] Join Query Perfomance Issue

On Feb 11, 2008 12:08 PM, Thomas Zaksek <[EMAIL PROTECTED]> wrote: > I have serious performance problems with the following type of queries: > / > /explain analyse SELECT '12.11.2007 18:04:00 UTC' AS zeit, >'M' AS datatyp, >p.zs_nr AS zs_de, >

Re: [PERFORM] Question about CLUSTER

On Feb 11, 2008 2:03 PM, salman <[EMAIL PROTECTED]> wrote: > Hello, > > I'm planning to cluster a few large tables in our database but I'm > unable to find any recommendations/documentation on best practices -- > Mainly, whether it's better to use an index which has a higher idx_scan > value, a hig

Re: [PERFORM] Update with Subquery Performance

On Feb 11, 2008 5:06 AM, Linux Guru <[EMAIL PROTECTED]> wrote: > We have a large datawarehouse stored in postgres and temp tables are created > based on user query. The process of temp table creation involves selecting > data from main fact table, this includes several select and update > statement

[PERFORM] Question about CLUSTER

Hello, I'm planning to cluster a few large tables in our database but I'm unable to find any recommendations/documentation on best practices -- Mainly, whether it's better to use an index which has a higher idx_scan value, a higher idx_tup_read value, or the higest idx_tup_fetch value. I'm assum

[PERFORM] Join Query Perfomance Issue

I have serious performance problems with the following type of queries: / /explain analyse SELECT '12.11.2007 18:04:00 UTC' AS zeit, 'M' AS datatyp, p.zs_nr AS zs_de, j_ges, de_mw_abh_j_lkw(mw_abh) AS j_lkw,

Re: [PERFORM] Update with Subquery Performance

"Linux Guru" <[EMAIL PROTECTED]> writes: > We have a large datawarehouse stored in postgres and temp tables are created > based on user query. The process of temp table creation involves selecting > data from main fact table, this includes several select and update > statements and one of the follo

Re: [PERFORM] Optimizer : query rewrite and execution plan ?

Simon Riggs <[EMAIL PROTECTED]> writes: > Say if cost of best plan >= N then recheck query for strangeness. If > anything found, re-plan query. Whatever makes you think that would be useful? The usual result of undetected duplicate WHERE clauses is an *underestimate* of runtime, not an overestima

[PERFORM] Update with Subquery Performance

We have a large datawarehouse stored in postgres and temp tables are created based on user query. The process of temp table creation involves selecting data from main fact table, this includes several select and update statements and one of the following update statement is having performance issue

Re: [PERFORM] Optimizer : query rewrite and execution plan ?

On Wed, 2008-02-06 at 11:00 -0500, Tom Lane wrote: > Theo Kramer <[EMAIL PROTECTED]> writes: > > On Wed, 2008-02-06 at 11:53 +, Simon Riggs wrote: > >> Since the SQL is not your fault and difficult to control, it is an > >> argument in favour of an optional planner mode that would perform > >>