On Thu, Apr 22, 2010 at 10:37 PM, Vlad Arkhipov arhi...@dc.baikal.ru wrote:
I don't think this is just an issue with statistics, because the same
problem arises when I try executing a query like this:
I'm not sure how you think this proves that it isn't a problem with
statistics, but I think
2010/4/23 Robert Haas robertmh...@gmail.com:
On Thu, Apr 22, 2010 at 10:37 PM, Vlad Arkhipov arhi...@dc.baikal.ru wrote:
I don't think this is just an issue with statistics, because the same
problem arises when I try executing a query like this:
I'm not sure how you think this proves that it
On Fri, Apr 23, 2010 at 9:09 AM, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
2010/4/23 Robert Haas robertmh...@gmail.com:
On Thu, Apr 22, 2010 at 10:37 PM, Vlad Arkhipov arhi...@dc.baikal.ru wrote:
I don't think this is just an issue with statistics, because the same
problem
Cédric Villemaincedric.villemain.deb...@gmail.com wrote:
2010/4/23 Robert Haas robertmh...@gmail.com:
Since all your data is probably fully cached, at a first cut, I
might try setting random_page_cost and seq_page_cost to 0.005 or
so, and adjusting effective_cache_size to something
2010/4/23 Robert Haas robertmh...@gmail.com:
On Fri, Apr 23, 2010 at 9:09 AM, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
2010/4/23 Robert Haas robertmh...@gmail.com:
On Thu, Apr 22, 2010 at 10:37 PM, Vlad Arkhipov arhi...@dc.baikal.ru
wrote:
I don't think this is just an
To answer the question of whether calling a stored procedure adds any
significant overhead, I built a test case and the short answer is that it
seems that it does:
CREATE OR REPLACE FUNCTION Test1() RETURNS INTEGER AS
$BODY$
DECLARE
temp INTEGER;
BEGIN
FOR i IN 1..1000 LOOP
SELECT
On Fri, Apr 23, 2010 at 4:42 PM, Eliot Gable
egable+pgsql-performa...@gmail.com wrote:
To answer the question of whether calling a stored procedure adds any
significant overhead, I built a test case and the short answer is that it
seems that it does:
CREATE OR REPLACE FUNCTION Test1() RETURNS
On Fri, Apr 23, 2010 at 3:22 PM, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
2010/4/23 Robert Haas robertmh...@gmail.com:
On Fri, Apr 23, 2010 at 9:09 AM, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
2010/4/23 Robert Haas robertmh...@gmail.com:
On Thu, Apr 22, 2010
On Fri, Apr 23, 2010 at 4:42 PM, Eliot Gable
egable+pgsql-performa...@gmail.com wrote:
And, from these tests, it would be significant overhead.
Yeah, I've been very disappointed by the size of the function-call
overhead on many occasions. It might be worth putting some effort
into seeing if
Robert Haas robertmh...@gmail.com writes:
Hmm. We currently have a heuristic that we don't record a value as an
MCV unless it's more frequent than the average frequency. When the
number of MCVs is substantially smaller than the number of distinct
values in the table this is probably a good
On Fri, Apr 23, 2010 at 6:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Hmm. We currently have a heuristic that we don't record a value as an
MCV unless it's more frequent than the average frequency. When the
number of MCVs is substantially smaller than
That's a good point. However, even after changing it, it is still 12ms with
the function call verses 6ms without the extra function call. Though, it is
worth noting that if you can make the function call be guaranteed to return
the same results when used with the same input parameters, it ends up
More benchmarking results are in with a comparison between cursors, arrays,
and temporary tables for storing, using, and accessing data outside the
stored procedure:
CREATE OR REPLACE FUNCTION Test_Init() RETURNS INTEGER AS
$BODY$
DECLARE
temp INTEGER;
BEGIN
DROP TABLE IF EXISTS test_table1
13 matches
Mail list logo
