Ron St-Pierre wrote:
I am using postgres 7.4.1 and have a problem with a plpgsql function.
When I run the function on the production server it takes approx 33
minutes to run. I dumped the DB and copied it to a similarly configured
box and ran the function and it ran in about 10 minutes. Can anyo
Tom Lane wrote:
Josh Berkus <[EMAIL PROTECTED]> writes:
A better way to set this would be to run VACUUM VERBOSE ANALYZE right after
doing one of your update batches, and see how many dead pages are being
reclaimed, and then set max_fsm_pages to that # + 50% (or more).
Actually, since he'
Josh Berkus <[EMAIL PROTECTED]> writes:
> A better way to set this would be to run VACUUM VERBOSE ANALYZE right after
> doing one of your update batches, and see how many dead pages are being
> reclaimed, and then set max_fsm_pages to that # + 50% (or more).
Actually, since he's running 7.4, the
Ron,
> Yeah I agree but I'm not allowed to remove those indexes.
It's not the indexes I'm talking about, it's the table.
> On my dev server I increased max_fsm_pages from the default of 2 to
> 4,
A better way to set this would be to run VACUUM VERBOSE ANALYZE right after
doing one of
Josh Berkus wrote:
Ron,
The emp table has 60 columns, all indexed, about two-thirds are numeric,
but they are not affected by this update. The other 50+ columns are
updated in the middle of the night and the amount of time that update
takes isn't a concern.
Well, I'd say that you have
Ron,
> The emp table has 60 columns, all indexed, about two-thirds are numeric,
> but they are not affected by this update. The other 50+ columns are
> updated in the middle of the night and the amount of time that update
> takes isn't a concern.
Well, I'd say that you have an application desi
I am using postgres 7.4.1 and have a problem with a plpgsql function.
When I run the function on the production server it takes approx 33
minutes to run. I dumped the DB and copied it to a similarly configured
box and ran the function and it ran in about 10 minutes. Can anyone
offer advice on t
LIANHE SHAO <[EMAIL PROTECTED]> writes:
> PGA=> explain select ei.expid, er.geneid,
> er.sampleid, ei.annotation, si.samplename,
> ei.title as exp_name, aaa.chip,
> aaa.sequence_derived_from as accession_number,
> aaa.gene_symbol, aaa.title as gene_function,
> er.exprs, er.mas5exprs from expressi
Hello,
Today I met a very strange query problem, which I
spend several hours on it but have no clue. To make
thing clear, let me write somewhat in detail.
I have two almost exactly same queries, except that
one is: lower(annotation) = lower (chip), another
is: annotation = chip. While the first o
"Rigmor Ukuhe" <[EMAIL PROTECTED]> writes:
>>> What causes this behaviour? is there any workaround? Suggestions?
At some point the planner is going to decide that one seqscan is cheaper
than repeated indexscans. At some point it'll be right ... but in this
case it seems its relative cost estimate
> There are about 2500 rows in that table.
>
> 1st query explain analyze: Seq Scan on PRIORITY_STATISTICS
> (cost=0.00..491.44 rows=127 width=12) (actual time=98.58..98.58 rows=0
> loops=1)
> Total runtime: 98.74 msec
>
> 2nd query explain analyze: NOTICE: QUERY PLAN:
>
> Index Scan using PRIORITY
> > What causes this behaviour? is there any workaround? Suggestions?
> >
>
> How many rows are there in the table, and can you post the
> 'explain analyze' for both queries after doing a 'vacuum verbose analyze
> [tablename]'?
There are about 2500 rows in that table.
1st query explain analyze: S
> What causes this behaviour? is there any workaround? Suggestions?
>
How many rows are there in the table, and can you post the 'explain analyze' for both
queries after doing a 'vacuum verbose analyze
[tablename]'?
Cheers
Matt
---(end of broadcast)--
Hi,
I have a table containing columns:
"END_DATE" timestamptz NOT NULL
"REO_ID" int4 NOT NULL
and i am indexed "REO_ID" coulumn.
I have a query:
select "REO_ID", "END_DATE" from "PRIORITY_STATISTICS" where "REO_ID" IN
('112851' ,'112859' ,'112871' ,'112883' ,'112891' ,'112904' ,'112915'
Hi,
I have a table containing columns:
"END_DATE" timestamptz NOT NULL
"REO_ID" int4 NOT NULL
and i am indexed "REO_ID" coulumn.
I have a query:
select "REO_ID", "END_DATE" from "PRIORITY_STATISTICS" where "REO_ID" IN
('112851' ,'112859' ,'112871' ,'112883' ,'112891' ,'112904' ,'11291
15 matches
Mail list logo
