Re: [PERFORM] Prepared statements vs. Stored Procedures

2005-06-22 Thread Radu-Adrian Popescu
I'm hoping someone can offer some advice here. I have a large perl script that employs prepared statements to do all its queries. I'm looking at using stored procedures to improve performance times for the script. Would making a stored procedure to replace each prepared statement be

Re: [PERFORM] Querying 19million records very slowly

2005-06-22 Thread Kjell Tore Fossbakk
database= set enable_seqscan to on; SET Time: 0.34 ms database= explain analyze select count(*) from test where p1=53; QUERY PLAN

Re: [PERFORM] Querying 19million records very slowly

2005-06-22 Thread Tobias Brox
[Kjell Tore Fossbakk - Wed at 09:45:22AM +0200] database= explain analyze select count(*) from test where p1=53 and time now() - interval '24 hours' ; Sorry to say that I have not followed the entire thread neither read the entire email I'm replying to, but I have a quick hint on this one (ref

Re: [PERFORM] Querying 19million records very slowly

2005-06-22 Thread Kjell Tore Fossbakk
Appreciate your time, Mr Brox. I'll test the use of current_timestamp, rather than now(). I am not sure if Pg can do a match between a fixed timestamp and a datetime? time current_timestamp - interval '24 hours', when time is -mm-dd hh-mm-ss+02, like 2005-06-22 16:00:00+02. If Pg cant do

Re: [PERFORM] Configurator project launched

2005-06-22 Thread Andreas Pflug
Greg Sabino Mullane wrote: Um, can't we just get that from pg_settings? Anyway, I'll be deriving settings from the .conf file, since most of the time the Configurator will be run on a new installation. Aren't most of the settings all kept in the SHOW variables anyway? As I said, it may

Re: [PERFORM] Querying 19million records very slowly

2005-06-22 Thread Tobias Brox
[Kjell Tore Fossbakk - Wed at 10:18:30AM +0200] I'll test the use of current_timestamp, rather than now(). I am not sure if Pg can do a match between a fixed timestamp and a datetime? I have almost all my experience with timestamps wo timezones, but ... isn't that almost the same as the

Re: [PERFORM] Querying 19million records very slowly

2005-06-22 Thread Kjell Tore Fossbakk
Try to type in '2005-06-21 16:36:22+08' directly in the query, and see if it makes changes. Or probably '2005-06-21 10:36:22+02' in your case ;-) Which one does Pg read fastes? Does he convert datetime in the table, then my where clause and check, for each row? How does he compare a datetime

[PERFORM] Forums tsearch2 - best practices reg. concurrency

2005-06-22 Thread Markus Wollny
Hello! We're using PostgreSQL 8.0.1 as general backend for all of our websites, including our online forums (aka bulletin boards or whatever you wish to call that). As for full text search capabilities, we've chosen to implement this via tsearch2. However, the tables themselves are quite large,

Re: [PERFORM] Querying 19million records very slowly

2005-06-22 Thread Tobias Brox
[Kjell Tore Fossbakk - Wed at 11:10:42AM +0200] Which one does Pg read fastes? Does he convert datetime in the table, then my where clause and check, for each row? How does he compare a datetime with a datetime? Timestamp are easy, large number bigger than another large number.. time

Re: [PERFORM] Forums tsearch2 - best practices reg. concurrency

2005-06-22 Thread Oleg Bartunov
Markus, wait for 8.1 which should solve all of these issues. We're working on GiST concurrency recovery right now. See http://www.pgsql.ru/db/mw/msg.html?mid=2073083 for details. Oleg On Wed, 22 Jun 2005, Markus Wollny wrote: Hello! We're using PostgreSQL 8.0.1 as general backend for all

Re: [PERFORM] Querying 19million records very slowly

2005-06-22 Thread Tom Lane
Tobias Brox [EMAIL PROTECTED] writes: time (datetime) '2005-06-21 10:36:22+02' or time (timestamp) 'some timestamp pointing to yesterday' If I have understood it correctly, the planner will recognize the timestamp and compare it with the statistics in the first example but not in the

Re: [PERFORM] Querying 19million records very slowly

2005-06-22 Thread Paul Ramsey
OK, so the planner is in fact making a mistake (I think). Try turning down your random_page_cost a little. It defaults at 4.0, see if 2.0 works right. (Careful, move these things around too much for one query, you will wreck others.) 4.0 is a little large for almost all modern hardware,

Re: [PERFORM] Querying 19million records very slowly

2005-06-22 Thread Kjell Tore Fossbakk
I cant get the config file to load into my postgres. that's the problem. I want to set it to 10k, but it is only still at 1000... I save the file and restart the service.. yes, i ment 'pg_ctl reload', sry about that one. kjell tore On 6/22/05, Bricklen Anderson [EMAIL PROTECTED] wrote:

[PERFORM] Performance Tuning Article

2005-06-22 Thread Frank Wiles
Hi Everyone, I've put together a short article and posted it online regarding performance tuning PostgreSQL in general. I believe it helps to bring together the info in a easy to digest manner. I would appreciate any feedback, comments, and especially any technical corrections.

Re: [PERFORM] Querying 19million records very slowly

2005-06-22 Thread Stefan Weiss
On 2005-06-22 10:55, Michael Glaesemann wrote: There has been discussion in the past on storing the time zone name with the timestamptz as well, though no one has implemented this yet. The reason for this may be that time zone names (abbreviations) are not unique. For example, ECT can mean

Re: [PERFORM] Limit clause not using index

2005-06-22 Thread Kevin Grittner
I just tried this on 8.0.3. A query which runs very fast through an index on a 25 million row table blocked when I dropped the index within a database transaction. As soon as I rolled back the database transactiton, the query completed, the index appears fine, and the query runs fast, as usual.

Re: [PERFORM] Querying 19million records very slowly

2005-06-22 Thread Tobias Brox
[Kjell Tore Fossbakk - Wed at 07:41:54AM -0700] I cant get the config file to load into my postgres. that's the problem. I want to set it to 10k, but it is only still at 1000... I save the file and restart the service.. yes, i ment 'pg_ctl reload', sry about that one. Classical problem, a

Re: [PERFORM] Performance Tuning Article

2005-06-22 Thread Josh Berkus
Frank, I've put together a short article and posted it online regarding performance tuning PostgreSQL in general. I believe it helps to bring together the info in a easy to digest manner. I would appreciate any feedback, comments, and especially any technical corrections. Looks

Re: [PERFORM] Performance Tuning Article

2005-06-22 Thread Frank Wiles
On Wed, 22 Jun 2005 10:16:03 -0700 Josh Berkus josh@agliodbs.com wrote: Frank, I've put together a short article and posted it online regarding performance tuning PostgreSQL in general. I believe it helps to bring together the info in a easy to digest manner. I would

Re: [PERFORM] Performance Tuning Article

2005-06-22 Thread Karim Nassar
On Wed, 2005-06-22 at 09:52 -0500, Frank Wiles wrote: I've put together a short article and posted it online regarding performance tuning PostgreSQL in general. Nice work! Some minor issues I saw: * section Understanding the process, para 5: Now that PostgreSQL has a plan of what it

[PERFORM] parameterized LIKE does not use index

2005-06-22 Thread Kurt De Grave
Hi, Consider the where-clauses: WHERE lower(col) LIKE 'abc'; WHERE lower(col) LIKE 'abc%'; these will both use a b-tree functional index in lower(col) if one exists. The clause WHERE lower(col) LIKE '%abc'; can't use the index as you would expect, because of the wildcard at the front. Thus,

Re: [PERFORM] parameterized LIKE does not use index

2005-06-22 Thread Josh Berkus
Kurt, Of course, I could modify the application and send different SQL depending on which case we're in or just constructing a query with a literal each time, but is there a way to add a hint to the SQL that would cause the query to be re-planned if it's a case that could use the index?  Or

Re: [PERFORM] Performance Tuning Article

2005-06-22 Thread Tobias Brox
[Frank Wiles - Wed at 09:52:27AM -0500] I've put together a short article and posted it online regarding performance tuning PostgreSQL in general. I believe it helps to bring together the info in a easy to digest manner. I would appreciate any feedback, comments, and especially any

Re: [PERFORM] Performance Tuning Article

2005-06-22 Thread Keith Worthington
I've put together a short article and posted it online regarding performance tuning PostgreSQL in general. I believe it helps to bring together the info in a easy to digest manner. I would appreciate any feedback, comments, and especially any technical corrections. Looks nice. You