[PERFORM] one column from huge view

Hello. I've googled a bit but I think I can't match the keywords, so I thought I'll ask here: Let's say I've got a view with 100 columns and 1mln rows; some of them are calculated "on the fly". For some reason I want only one column from this view: select col1 from huge_view; Now, does PostgreS

Re: [PERFORM] performance of like queries

On 10/2/07, Kevin Kempter <[EMAIL PROTECTED]> wrote: > Hi List; > > any suggestions for improving "LIKE '%text%'" queries? http://www.depesz.com/index.php/2007/09/15/speeding-up-like-xxx/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaste

Re: [PERFORM] SQL Monitoring

On 10/9/07, Campbell, Lance <[EMAIL PROTECTED]> wrote: > I have noticed a slight spike in the amount of CPU usage in the last few > weeks. I am sure it has to do with a change or two that was made to some > queries. What is the best way to log the SQL that is being executed? I > would prefer to

Re: [PERFORM] Shared Buffer setting in postgresql.conf

On 10/9/07, Radhika S <[EMAIL PROTECTED]> wrote: > Hi, > Along with my previous message (slow postgres), I notice the shared buffer > setting for our production database is set to 1000. > How much higher can I go? I don't know how much my kernel can take? A lot higher. How much memory do you have

Re: [PERFORM] using a stored proc that returns a result set in a complex SQL stmt

On 10/16/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: > > The only reason I am going down this road is because of the difficulty of > > using temp tables ( i.e. needing to execute a SQL string). Does anyone know > > if this requirement may be removed in the near future? > > I don't understand

Re: [PERFORM] Slow set-returning functions

Dnia 27-01-2008, N o godzinie 17:29 +, Dean Rasheed pisze: > The CONTEXT is very useful, particularly when functions call other > functions, since it gives the call stack (presumably only for SQL and > PL/pgSQL functions). For top-level queries I would ideally like the > CONTEXT to log the SQL

Re: [PERFORM] LIKE Query performance

On Wed, Jan 28, 2009 at 12:41 AM, Hari, Balaji wrote: > EXPLAIN ANALYZE SELECT event_id, category, current_session_number, > description, event_type_id, realm_name, root_session_number, severity, > source_name, target_key, target_name, timestamp, jdo_version FROM event > WHERE description like '%m

Re: [PERFORM] Hosted servers with good DB disk performance?

On Tue, May 26, 2009 at 11:51 PM, Greg Smith wrote: > I keep falling into situations where it would be nice to host a server > somewhere else.  Virtual host solutions and the mysterious cloud are no good > for the ones I run into though, as disk performance is important for all the > applications

Re: [PERFORM] slow DELETE on 12 M row table

On Fri, Jun 26, 2009 at 9:34 AM, Janet Jacobsen wrote: > I assume that killing the user's process released the lock on the > table.  This user has only SELECT privileges.  Under what > conditions would a SELECT lock a table.  The user connects > to the database via a (Python?) script that runs on

Re: [PERFORM] Full text search with ORDER BY performance issue

On Sun, Jul 19, 2009 at 12:07 AM, Krade wrote: > archive=> explain analyze select * from a where  comment_tsv @@ > plainto_tsquery('love') order by timestamp desc limit 24 offset 0; What happens if you make it: select * from ( select * from a where comment_tsv @@plainto_tsquery('love')