umber of rows
did you try to add a 'order by date' clause to your query ?
gnari
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
gt;
> We never had any upgrade on it.
7.2 is a bit dated now that 8.0 is in beta
if you want to stay with 7.2, you should at least upgrade
to the latest point release (7.2.6 ?), as several serious bugs
have been fixed
gnari
---(end of broadcast)
From: "BBI Edwin Punzalan" <[EMAIL PROTECTED]>
>
> Yes, the database is being vacuum-ed and analyzed on a daily basis.
>
then you should consider increating the statistics on the date column,
as the estimates were a bit off in the plan
> Our version is
> time=0.45..4268.00 rows=23787 loops=1)
> Total runtime: 4282.81 msec
> ==
>
> How come a query on the current date filter uses an index and the others
> does not? This makes indexing to speed up queries quite difficult.
have you ANALYZED the table lately ?
what v
, as I am new to
Postgres. What does it signify and how do I reduce random_page_cost?
set random_page_cost = 3;
explain analyse
if it is an improvement, consider setting the value in your postgresql.conf,
but remember that this may affect other queries too.
gnari
---
WHERE CUSTOMER_ID=5::bigint
or
SELECT * FROM CUSTOMER WHERE CUSTOMER_ID='5'
gnari
---(end of broadcast)---
TIP 8: explain analyze is your friend
> column.
add a new column, use update to copy values from old column,
use alter table to rename columns
gnari
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
I ("gnari" <[EMAIL PROTECTED]>) miswrote:
> Actually, I think it was determined that the problem was due to the
> int index
of course, i meant int8 index
gnari
---(end of broadcast)---
TIP 8: explain analyze is your friend
hink it was determined that the problem was due to the
int index
Michal Taborsky suggested this solution:
select id from test where id = 5::int8
did this not help ?
gnari
---(end of broadcast)---
TIP 8: explain analyze is your friend
inserts / 5 minutes, then this will not help
gnari
>
> Cheers,
> Guido
>
> > "G u i d o B a r o s i o" <[EMAIL PROTECTED]> wrote:
> >
> > [speeding up 100 inserts every 5 minutes]
> >
> > > Tips!
> > > *Delete ind
"G u i d o B a r o s i o" <[EMAIL PROTECTED]> wrote:
[speeding up 100 inserts every 5 minutes]
> Tips!
> *Delete indexes and recreate them after the insert.
sounds a bit extreme, for only 100 inserts
gnari
---(end of broadcast)---
"Merlin Moncure" <[EMAIL PROTECTED]> wrote:
-- optional
cluster user_message_idx messages;
would one not have to repeat this operation regularly, to keep
any advantage of this ? my impression was that this is a relatively
heavy operation on a lar
ow much effect does this setting have on the planner?
is there a recommended procedure to estimate
the best value for effective_cache_size on a
dedicated DB server ?
gnari
---(end of broadcast)---
TIP 2: you can get off all lists at once with the
13 matches
Mail list logo
