Re: [PERFORM] Slow query (wrong index used maybe)

2014-01-28 Thread Stelian Iancu


On Mon, Jan 27, 2014, at 11:43, Gavin Flower wrote:
 On 28/01/14 08:10, bobJobS wrote:
  My developers have had the same issue.
 
  Postgres 9.2.3 on Linux 5.6.
 
 The latest Linux kernel is 3.13 (https://www.kernel.org), so I assume 
 5.6 is a distribution version.
 
 So which distribution of Linux are you using?
 
 

I cannot reply for Bob, but we're on Debian 7. 

 Cheers,
 Gavin
 
 
 -- 
 Sent via pgsql-performance mailing list
 (pgsql-performance@postgresql.org)
 To make changes to your subscription:
 http://www.postgresql.org/mailpref/pgsql-performance


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance


Re: [PERFORM] Slow query (wrong index used maybe)

2014-01-28 Thread bobJobS
RHEL 5.10 kernel 2.6.18



--
View this message in context: 
http://postgresql.1045698.n5.nabble.com/Slow-query-wrong-index-used-maybe-tp5788979p5789206.html
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance


Re: [PERFORM] Select hangs and there are lots of files in table and index directories.

2014-01-28 Thread Peter Blair
Tom,

You are correct.  The was an infinate loop created because of the
differences in the date math between Oracle and Postgres.

Thank again for your help.
On Mon, Jan 27, 2014 at 7:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:

 Peter Blair petertbl...@gmail.com writes:
  Have a problem where a stored procedure is taking a week to run.  The
  stored procedure should take less than a second to run.

 Is that it's known to terminate if you give it a week, or we've let
 it run for a week and it shows no sign of ever terminating?

  In researching a
  select hanging problem, three things are suggested; an autovacuum
 problem,
  a resource is locked, or there is something wrong with the stored
 procedure.

 I'd bet on the last, given that you're apparently working with an immature
 port from Oracle.  The error recovery semantics, in particular, are enough
 different in PL/SQL and PL/pgSQL that it's not too hard to credit having
 accidentally written an infinite loop via careless translation.

  Lastly, in the directories used to store the tables and indexes, there
 are
  918896 files in the tables directory and 921291 files in the indexes
  directory.  All of the file names are just numbers (no extensions).
  About
  60 files are added to each directory every second.  On our test systems
 and
  at our other customer site, there are only about 50 files in each
 directory.
  Why are there so many files?

 If the filenames are just numbers, then they must be actual tables or
 indexes, not temp files.  (You could cross-check that theory by noting
 whether the system catalogs, such as pg_class, are bloating at a
 proportional rate.)  I'm guessing that there's some loop in your procedure
 that's creating new temp tables, or maybe even non-temp tables.  You would
 not be able to see them via select * from pg_class in another session
 because they're not committed yet, but they'd be taking up filesystem
 entries.  The loop might or might not be dropping the tables again; IIRC
 the filesystem entries wouldn't get cleaned up till end of transaction
 even if the tables are nominally dropped.

 Not much to go on, but I'd look for a loop that includes a CREATE TABLE
 and a BEGIN ... EXCEPT block, and take a close look at the conditions
 under which the EXCEPT allows the loop to continue.

 regards, tom lane