Hi Jeff,
Instead what I get is the index only scan (to provide order) feeding into a
> Group.
>
That's interesting. We tested out in two versions of Postgres (9.2 and 9.3)
in different Mac machines and ended up with index-only scan only after the
partial index. I remember doing a vacuum full anal
Right, not refering triggers, seems to be kind of mix C/sql compiled (=
external).
To conclude :
- pl/proxy, it appears difficult, and not designed to.
- pgAgent (supposed to apply jobs in a multithreaded way)
- bash (xargs does the job)
- external scripts (R, python, perl...)
So I will test pgAg
On 4 April 2014 21:26, PARIS Nicolas wrote:
> this postgres documentation :
> http://www.postgresql.org/docs/9.3/static/ecpg-connect.html
> says it is actually possible to manage connection in C stored procedure.
>
> I may be wrong...
That page doesn't refer to triggers at all, so I'm still not s
On Friday, April 4, 2014, Varadharajan Mukundan
wrote:
> Hi Jeff,
>
> It looks like the original emailer wrote a query that the planner is not
>> smart enough to plan properly (A known limitation of that kind of query).
>> He then made a bunch of changes, none of which worked. He then re-wrote
Ryan Johnson writes:
> I get a strange behavior across repeated runs: each 100-second run is a
> bit slower than the one preceding it, when run with SSI (SERIALIZABLE).
> ... So the question: what should I look for to diagnose/triage this problem?
In the past I've seen behaviors like this that
On 04/06/2014 05:25 AM, Ryan Johnson wrote:
I've tried linux perf, but all it says is that lots of time is going to
LWLock (but callgraph tracing doesn't work in my not-bleeding-edge
kernel).
Make sure you compile with the "-fno-omit-frame-pointer" flag.
- Heikki
--
Sent via pgsql-performance
