Title: RE: [PERFORM] Why is plan (and performance) different on partitioned table?
>If you don't have anything in the parent table br_1min, then deleting
>the (presumably obsolete) pg_statistic rows for it should fix your
>immediate problem. Otherwise, consider applying the attached.
Tom,
Title: Why is plan (and performance) different on partitioned table?
Hi,
I have recently implemented table partitioning in our postgres 8.1 db. Upon analyzing query performance, I have realized that, even when only a single one of the "partitions" has to be scanned, the plan is drastically d
Title: RE: [PERFORM] SQL Function Performance
> in my case; both direct query and sql function gererate same execution plan. Also, execution plan belongs to the sql function better than direct sql > query plan. But, direct sql result comes less than 1 second. sql function result comes about i
Title: RE: [PERFORM] SQL Function Performance
I've run into this issue. It basically comes down to the plan that is being used inside the function is not the same as the plan used when you issue the query manually outside of the function. Although I'm no expert on when plans are prepared and
Hi,
I've got a set-returning function, defined as STABLE, that I reference twice
within a single query, yet appears to be evaluated via two seperate function
scans. I created a simple query that calls the function below and joins the
results to itself (Note: in case you wonder why I'd do suc
On Thursday 05 January 2006 15:12, Qingqing Zhou wrote:
> "Mark Liberman" <[EMAIL PROTECTED]> wrote
>
> > First run, after a night of inactivity:
> >
> > -> Bitmap Index Scan on
> > 1min_events_file_id_begin_idx (cost=0.00..
Hello,
We have a web-application running against a postgres 8.1 database, and
basically, every time I run a report after no other reports have been run for
several hours, the report will take significantly longer (e.g. 30 seconds),
then if I re-run the report again, or run the report when the w
