Rajesh Kumar Mallah | 1 Nov 2003 06:47

[ PROBLEM SOLVED ] Re: Query puts 7.3.4 on endless loop but 7.4beta5 is fine.


Well Sorry everyone ,

The problem was tracked down to a silly
datatype mismatch between two join columns
in table Groups(instance) and Tickets(id)
(int vs varchar )

7.4b5 is automatically taking care of this
mismatch hence it was getting executed there.

But , The problem is will this behaviour not 
allow to go such mistakes unnoticed?

Regards
Mallah.

On Friday 31 Oct 2003 4:08 am, Greg Stark wrote:
> Well, you might want to try the EXISTS version. I'm not sure if it'll be
> faster or slower though. In theory it should be the same.
>
> Hum, I didn't realize the principals table was the largest table. But
> Postgres knew that so one would expect it to have found a better plan. The
> IN/EXISTS handling was recently much improved but perhaps there's still
> room :)
>
> SELECT *
>   FROM tickets
>  WHERE EXISTS (
>        SELECT 1
(Continue reading)

Greg Stark | 2 Nov 2003 17:33
Picon
Favicon

Re: Pg+Linux swap use


William Yu <wyu <at> talisys.com> writes:

> Rob Sell wrote:
>
> > Not being one to hijack threads, but I haven't heard of this performance hit
> > when using HT, I have what should all rights be a pretty fast server, dual
> > 2.4 Xeons with HT 205gb raid 5 array, 1 gig of memory. And it is only 50% as
> > fast as my old server which was a dual AMD MP 1400's with a 45gb raid 5
> > array and 1gb of ram. 
> 
> Not to get into a big Intel vs AMD argument but 50% sounds about right. Let's
> first assume that the QS rating for the MP1400 is relatively accurate and
> convert that to a 1.4GHz Xeon. 2.4/1.4 = +71%. Since processor performance
> does not increase linearly with clockspeed, 50% is in line with expectations.

Hm. You've read "50% as fast" as "50% faster". 
I wonder which the original poster intended.

--

-- 
greg

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Lee Hughes | 3 Nov 2003 17:20

join_collapse_limit, from_collapse_limit options missing

Hi, I'm trying to set these two options to tune performance but both
return 'not a valid option name'. Dumping the pg_settings table confirms
that they are missing. I'm using the PostgreSQL packages included with
RedHat 9 (7.3.2) and Mandrake 9.2 Beta (7.3.4). Do I need to install the
full tarball to get these options? Any help greatly appreciated.

Thanks, Lee

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to majordomo <at> postgresql.org so that your
      message can get through to the mailing list cleanly

Tom Lane | 3 Nov 2003 17:24
Picon

Re: join_collapse_limit, from_collapse_limit options missing

"Lee Hughes" <lee <at> owensforestproducts.com> writes:
> Hi, I'm trying to set these two options to tune performance but both
> return 'not a valid option name'. Dumping the pg_settings table confirms
> that they are missing. I'm using the PostgreSQL packages included with
> RedHat 9 (7.3.2) and Mandrake 9.2 Beta (7.3.4). Do I need to install the
> full tarball to get these options? Any help greatly appreciated.

They don't exist in 7.3.  Why are you consulting 7.4 documentation for a
7.3 installation?

			regards, tom lane

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

               http://archives.postgresql.org

Josh Berkus | 3 Nov 2003 19:41

Re: join_collapse_limit, from_collapse_limit options missing

Lee,

> Hi, I'm trying to set these two options to tune performance but both
> return 'not a valid option name'. Dumping the pg_settings table confirms
> that they are missing. I'm using the PostgreSQL packages included with
> RedHat 9 (7.3.2) and Mandrake 9.2 Beta (7.3.4). Do I need to install the
> full tarball to get these options? Any help greatly appreciated.

If you're working from the documentation on General Bits, please notice that 
both of those options are marked as "new for 7.4".

--

-- 
Josh Berkus
Aglio Database Solutions
San Francisco

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

               http://archives.postgresql.org

Cestmir Hybl | 4 Nov 2003 11:43
Picon

Re: Ignoring index on (A is null), (A is not null) conditions

First of all, thanks for all your suggestions.

They were of two classes:

1. use different data representation (special constant from column domain
instead of NULL)

This is possible, of course, but it makes data model less portable and
requires changes in database abstraction layer of application.

2. use partial indexes

This is suitable for single null-allowed column index. With increasing
number of null-allowed columns inside index, the number of partial indexes
required grows exponentially.

All RDBMSs I ever used (Sybase, MSSQL, or even MySQL) were using index to
filter by expressions containing is NULL conditions /(A is NULL), (A is not
NULL), (A is NULL or A = const), (A is NULL or A > const)/ so it seems
pretty strange to me that PostgreSQL does not.

Is this sheduled feature at least?

CH

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to majordomo <at> postgresql.org)

(Continue reading)

radha.manohar | 4 Nov 2003 15:49
Picon
Picon

Re: Response time

How do we measure the response time in postgresql?

Your response would be very much appreciated.

Thanks and Regards,

Radha

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Pavel Stehule | 4 Nov 2003 16:02
Picon
Picon

Re: Response time

Hello

explain analyse select * from lidi;
                                          QUERY PLAN

-----------------------------------------------------------------------------------------------
 Seq Scan on lidi  (cost=0.00..1.04 rows=4 width=96) (actual 
time=0.046..0.092 rows=4 loops=1)
 Total runtime: 0.369 ms

Regards
Pavel

On Tue, 4 Nov 2003 radha.manohar <at> ndsu.nodak.edu wrote:

> How do we measure the response time in postgresql?
> 
> Your response would be very much appreciated.
> 
> Thanks and Regards,
> 
> Radha
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 

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

Neil Conway | 4 Nov 2003 21:12

Re: Response time

On Tue, 2003-11-04 at 09:49, radha.manohar <at> ndsu.nodak.edu wrote:
> How do we measure the response time in postgresql?

In addition to EXPLAIN ANALYZE, the log_min_duration_statement
configuration variable and the \timing psql command might also be
useful.

-Neil

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Paul Ganainm | 5 Nov 2003 11:28
Picon
Favicon

Interbase/Firebird - any users out there - what's the performance like compared to PostgreSQL?


Hi all,

I have just started with PostgreSQL on Linux and in the past I've done a 
good bit of work on Interbase (both on Windows and Linux).

What I want to know here is

What do people here think of Interbase/Firebird?

Has anybody done performance metrics or could they point me to a 
comparison between the two?

Does Interbase/Firebird have (as far as people here are concerned) any 
show-stoppers in terms of functionality which they do have on 
PostgreSQL? Or, indeed, the other way round?

I'm not interested in starting a flame war or anything like that - just 
a presentation of the facts as you see them, and if you want to put in 
your opinion also, that's fine, just make a note!

TIA.

Paul...

--

-- 

plinehan__AT__yahoo__DOT__com

C++ Builder 5 SP1, Interbase 6.0.1.6 IBX 5.04 W2K Pro
(Continue reading)


Gmane