und then having workers equal to
h/w threads would be beneficial since less time will spent in CPU,
however if the task is CPU bound then workers more than cpu cores is
not likely to give much performance improvement as they'll be
contending for CPU cycles.
--
Regards,
Rafia Sabi
>
>
>
> Event a “limit 100” does not use the index any more.
>
>
>
> However, the result of 4728 ms is almost a linear increase from 10 rows to
> 13500 rows.
>
>
>
> I played around with COST of the function between 1 and 2 and with
> several options on postgresql.conf without luck.
>
>
>
> A sequential scan on the order table alone is carried out in 15 ms.
>
>
>
> Thanks for any idea.
>
>
>
> Klaus
>
>
>
Notice the number of output rows in both the cases, when number of output
rows is low enough usage of index is beneficial otherwise it'll be costly
to have that many random accesses.
Anyhow, if you want to check the performance of an indexed plan for such a
query, try lowering down the value of random_page_cost.
--
Regards,
Rafia Sabih
EnterpriseDB: http://www.enterprisedb.com/
| not null default
> '0.0.0.0'::inet
> ip_dst | inet| not null default
> '0.0.0.0'::inet
> Indexes:
> "netflow_pkey" PRIMARY KEY, btree (id)
> "netflow_ts_key" btree (stamp_inserted)
> "netflow_tsu_idx" btree (stamp_updated)
> Triggers:
> netflow_import AFTER INSERT OR UPDATE ON netflow FOR EACH STATEMENT
> EXECUTE PROCEDURE netflow_update()
>
>
Is this some one-time event or you could reproduce it consistently?
--
Regards,
Rafia Sabih
EnterpriseDB: http://www.enterprisedb.com/
statements. Only if we consider the popular method of dump-restore
mentioned in the thread (https://www.postgresql.org/
message-id/E1VYMqi-0001P4-P4%40wrigleys.postgresql.org) with pg_dumpall -g
and then individual pg_dump, then it would be helpful to have this patch.
Regards,
Rafia Sabih
EnterpriseDB
On Tue, Jul 5, 2016 at 06:39 AM, Haribabu Kommi
kommi(dot)haribabu(at)gmail(dot)com wrote:
Still i feel the GRANT statements should be present, as the create
database statement
is generated only with -C option. So attached patch produces the GRANT
statements based
on the -x option.
The attached
