KC wrote:
>
> So I guess it all comes back to the basic question:
>
> For the query select distinct on (PlayerID) * from Player a where
> PlayerID='0' order by PlayerId Desc, AtDate Desc;
> can the optimizer recognise the fact the query is selecting by the
primary
> key (PlayerID,AtDate), so
Dear Merlin and all,
That direct SQL returns in 0 ms. The problem only appears when a view is used.
What we've done to work around this problem is to modify the table to add a
field DataStatus which is set to 1 for the latest record for each player,
and reset to 0 when it is superceded.
A pa
Hi all,
After a long time of reading the general list it's time to subscribe to
this one...
We have adapted our application (originally written for oracle) to
postgres, and switched part of our business to a postgres data base.
The data base has in the main tables around 150 million rows, the wh
> Hi all,
>
> After a long time of reading the general list it's time to subscribe to
> this one...
>
> We have adapted our application (originally written for oracle) to
> postgres, and switched part of our business to a postgres data base.
>
> The data base has in the main tables around 150 milli
[snip]
> Have you tried reindexing your active tables?
>
Not yet, the db is in production use and I have to plan for a down-time
for that... or is it not impacting the activity on the table ?
> Emil
>
> ---(end of broadcast)---
> TIP 9: In versions
> [snip]
>
> > Have you tried reindexing your active tables?
>
> Not yet, the db is in production use and I have to plan for a down-time
> for that... or is it not impacting the activity on the table ?
>
It will cause some performance hit while you are doing it. It sounds like
something is bloati
> The disk used for the data is an external raid array, I don't know
much
> about that right now except I think is some relatively fast IDE stuff.
> In any case the operations should be cache friendly, we don't scan
over
> and over the big tables...
Maybe you are I/O bound. Do you know if your RA
On 10/12/05, Csaba Nagy <[EMAIL PROTECTED]> wrote:
> We have adapted our application (originally written for oracle) to
> postgres, and switched part of our business to a postgres data base.
> The data base has in the main tables around 150 million rows, the whole
> data set takes ~ 30G after the
Ok, that was the first thing I've done, checking out the explain of the
query. I don't really need the analyze part, as the plan is going for
the index, which is the right decision. The updates are simple one-row
updates of one column, qualified by the primary key condition.
This part is OK, the qu
Emil Briggs <[EMAIL PROTECTED]> writes:
>> Not yet, the db is in production use and I have to plan for a down-time
>> for that... or is it not impacting the activity on the table ?
> It will cause some performance hit while you are doing it.
It'll also lock out writes on the table until the index
Would it not be faster to do a dump/reload of the table than reindex or
is it about the same?
Steve Poe
On Wed, 2005-10-12 at 13:21 -0400, Tom Lane wrote:
> Emil Briggs <[EMAIL PROTECTED]> writes:
> >> Not yet, the db is in production use and I have to plan for a down-time
> >> for that... or i
>
> Would it not be faster to do a dump/reload of the table than reindex
or
> is it about the same?
>
reindex is probably faster, but that's not the point. you can reindex a
running system whereas dump/restore requires downtime unless you work
everything into a transaction, which is headache, and
On Wed, Oct 12, 2005 at 06:55:30PM +0200, Csaba Nagy wrote:
> Ok, that was the first thing I've done, checking out the explain of the
> query. I don't really need the analyze part, as the plan is going for
> the index, which is the right decision. The updates are simple one-row
How do you know? Y
13 matches
Mail list logo
