Re: [GENERAL] postgres_fdw - push down conditionals for ENUMs

2014-07-25 Thread Sergiy Zuban
> > > 1. Is there any plans to add "non-strict mode" (configurable via options > on > > server/table/column level) to allow pushing down conditions for all data > > types? > > No. You might as well call it a "return random answers" mode. > Its bad. I think most users would be happy to have "auto

Re: [GENERAL] tab_to_sting

2014-07-25 Thread Ramesh T
Hi, when i ran below statement its working fine.. select string_agg(part_id::text,':') from part; But, SELECT tab_to_largeStringcheck(cast(string_agg(part_id::text,':')as t_varchar2_tab)) FROM part [image: Inline image 1] when i ran like SELECT qa.tab_to_largeStringcheck(string_agg(part_id

Re: [GENERAL] Checkpoint_segments optimal value

2014-07-25 Thread John R Pierce
On 7/25/2014 5:58 PM, Prabhjot Sheena wrote: We do have i/o problem during heavy loads because we share mount point from netapp across different machines which we are getting rid in few weeks by moving stuff to Amazon aws and than IO issues will go away with fast iops Netapp has to be some of

Re: [GENERAL] Checkpoint_segments optimal value

2014-07-25 Thread Prabhjot Sheena
Thanks a lot Kevin. This is what i did to improve query performance. i recreated all the indexes on work_unit table and have been running vacuum analyze through cron job 3 times a day on two tables that are in the query. The query performance is between 2 to 3 seconds now. The strange thing i noti

Re: [GENERAL] copy/dump database to text/csv files

2014-07-25 Thread Marc Mamin
This is probably an easy one for most sql users but I don't use it very often. > > > >We have a postgres database that was used for an application we no longer use. > However, we would > >like to copy/dump the tables to files, text or csv so we can post them to >sharepoint. > > > >Copy seems to b

Re: [GENERAL] Index usage with slow query

2014-07-25 Thread Marc Mamin
>The presence of absence of the length limiter on a varchar will not impact >the query plan. And I'm pretty sure you cannot even store a too long >varchar in an index. It will error on the attempt (as opposed to >truncating). The max size is almost one block. After that you get an error: FEHL

Re: [GENERAL] event triggers in 9.3.4

2014-07-25 Thread Alvaro Herrera
Pavel Stehule wrote: > Hello > > I found a interesting extension > http://code.malloclabs.com/pg_schema_triggers Ah, I remember that. I find that approach more cumbersome to use than mine. Note the ALTER cases can't tell you much about exactly how the relation has changed; you have to run compa

Re: [GENERAL] Index usage with slow query

2014-07-25 Thread David G Johnston
Bill Moran wrote > On Fri, 25 Jul 2014 17:20:57 +0100 > Rebecca Clarke < > r.clarke83@ > > wrote: > > Note that this is speculation on my part, but the > point being that if those columns are usually as narrow as your > examples you might want to try changing them to VARCHAR(50) or > something a

Re: [GENERAL] event triggers in 9.3.4

2014-07-25 Thread Pavel Stehule
Hello I found a interesting extension http://code.malloclabs.com/pg_schema_triggers Regards Pavel 2014-07-25 20:01 GMT+02:00 Alvaro Herrera : > Vasudevan, Ramya wrote: > > >> You could compare list of tables before (_start) and after (_end) the > ddl. Doing it in plpgsql will be tricky, but i

Re: [GENERAL] copy/dump database to text/csv files

2014-07-25 Thread Francisco Olarte
Hi William: On Thu, Jul 24, 2014 at 9:04 PM, William Nolf wrote: > We have a postgres database that was used for an application we no longer > use. However, we wouldlike to copy/dump the tables to files, text or csv > so we can post them to sharepoint. > How BIG is your public schema? A

Re: [GENERAL] Index usage with slow query

2014-07-25 Thread Bill Moran
On Fri, 25 Jul 2014 17:20:57 +0100 Rebecca Clarke wrote: > Hi Bill, > > Thanks for the reply. Here's the EXPLAIN output of a couple of the queries: A few suggestions in addition to David's comment about doing EXPLAIN ANALYZE: 1) When experimenting, one thing to try might be making a single G

Re: [GENERAL] event triggers in 9.3.4

2014-07-25 Thread Alvaro Herrera
Vasudevan, Ramya wrote: > >> You could compare list of tables before (_start) and after (_end) the ddl. > >> Doing it in plpgsql will be tricky, but if you'd use some other language - > >> like plperl - it's relatively simple: > >> http://www.depesz.com/2013/12/18/waiting-for-9-4-plperl-add-eve

Re: [GENERAL] Index usage with slow query

2014-07-25 Thread David G Johnston
Rebecca Clarke-2 wrote > Thanks for the reply. Here's the EXPLAIN output of a couple of the > queries: Typically you want to provide EXPLAIN ANALYZE output so that comparisons between planner estimates and reality can be made. David J. -- View this message in context: http://postgresql.1045

Re: [GENERAL] event triggers in 9.3.4

2014-07-25 Thread Vasudevan, Ramya
>> Sure - just check differences in appropriate catalogs. pg_attribute, >> pg_trigger, pg_proc. >> In any way - if you want to really use it - you'll have to write in C. Thank You Depesz. I think that answered my question. Thank You Ramya

Re: [GENERAL] Index usage with slow query

2014-07-25 Thread Rebecca Clarke
Hi Bill, Thanks for the reply. Here's the EXPLAIN output of a couple of the queries: SELECT the_geom,oid from mytable where the_geom && ST_GeomFromText('POLYGON((529342.334095833 180696.22173,529342.334095833 181533.44595,530964.336820833 181533.44595,530964.336820833 180696.22173,529342

Re: [GENERAL] event triggers in 9.3.4

2014-07-25 Thread hubert depesz lubaczewski
On Thu, Jul 24, 2014 at 7:13 PM, Vasudevan, Ramya < ramya.vasude...@classmates.com> wrote: > >> You could compare list of tables before (_start) and after (_end) the > ddl. Doing it in plpgsql will be tricky, but if you'd use some other > language - like plperl - it's relatively simple: > http://