see
http://stackoverflow.com/questions/26237463/bad-optimization-planning-on-postgres-window-based-queries-partition-by-group
for details
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Bad-optimization-planning-on-Postgres-window-based-queries-partition-by-group-by-100
On 10/07/2014 04:41 PM, Sergey Konoplev wrote:
On Thu, Oct 2, 2014 at 4:00 PM, George Neuner wrote:
--- code
CREATE OR REPLACE FUNCTION gen_random()
RETURNS double precision AS
$BODY$
DECLARE
num float8 := 0;
den float8 := 281474976710655; -- 0xF
On Thu, Oct 2, 2014 at 4:00 PM, George Neuner wrote:
> --- code
> CREATE OR REPLACE FUNCTION gen_random()
> RETURNS double precision AS
> $BODY$
> DECLARE
>num float8 := 0;
>den float8 := 281474976710655; -- 0x
>bytes bytea[6];
> BEGIN
>
On Fri, Oct 3, 2014 at 6:38 PM, Andrey Lizenko wrote:
> Is it possible to force optimizer choose the second plan without doing "set
> enable_hashjoin = off;" ?
>
> Increasing of 'effective_cache_size' leads to similar thing with mergejoin,
> other options (work_mem, shared_buffers. etc) do not c
Thanks for your reply. Adding '-c fast' does seem to improve the initial
delay. I'm still seeing delays of several minutes between write bursts.
The server has light OLTP loading.
__
*Mike Blackwell | Technical Analy
Hi,
I have similar problem as in
http://www.postgresql.org/message-id/flat/52b311c4.1070...@gmail.com#52b311c4.1070...@gmail.com
server version is 9.3.4
Here is only two quite simple tables:
db_new=# \d activities_example
Table "public.activities_example"
Column | Type | Modifiers
Hi,
I am using Postgresql 9.3.5 on Ubuntu and I have a sudden, unexplained
failure in a function that has been working for a long time.
--- code
CREATE OR REPLACE FUNCTION gen_random()
RETURNS double precision AS
$BODY$
DECLARE
num float8 := 0;
den floa
Vladimir Kamarzin writes:
> After upgrade from 9.3.1 to 9.3.5 we expirienced a slight performance
> degradation of all queries. Query time increased to some amount of ms, mostly
> in range of 100ms. Some actions in our application results in a lot of small
> queries and in such cases performanc
After upgrade from 9.3.1 to 9.3.5 we expirienced a slight performance
degradation of all queries. Query time increased to some amount of ms, mostly
in range of 100ms. Some actions in our application results in a lot of small
queries and in such cases performance degradation is very significant -
