You can try using the pg_stat_io table and related stat tables to figure out
which ones are responsible for all this I/O on startup.
Then, for the big offenders issue a select count(*) on those right at the
start, to force the OS to read the pages into memory. This won't be effective
if these a
Wei Yan wrote:
Hi:
Our queries are extremely slow only after db server reboot, not after
restart postgres db only. The difference is about 10 mins vs. 8 secs.
Not acceptable. I have browsed around , set the postgres db parameters
as suggested. Still the same.
Any suggestion on how to tackle
Hi:
Our queries are extremely slow only after db server reboot, not after
restart postgres db only. The difference is about 10 mins vs. 8 secs. Not
acceptable. I have browsed around , set the postgres db parameters as
suggested. Still the same.
Any suggestion on how to tackle the problem?
Thanks
On Mon, Feb 9, 2009 at 10:44 AM, justin wrote:
> Matthew Wakeling wrote:
>>
>> On Sat, 7 Feb 2009, justin wrote:
>>>
>>> In a big databases a checkpoint could get very large before time had
>>> elapsed and if server cashed all that work would be rolled back.
>>
>> No. Once you commit a transaction
Matthew Wakeling wrote:
On Sat, 7 Feb 2009, justin wrote:
In a big databases a checkpoint could get very large before time had
elapsed and if server cashed all that work would be rolled back.
No. Once you commit a transaction, it is safe (unless you play with
fsync or asynchronous commit). Th
On Sat, 7 Feb 2009, justin wrote:
In a big databases a checkpoint could get very large before time had
elapsed and if server cashed all that work would be rolled back.
No. Once you commit a transaction, it is safe (unless you play with fsync
or asynchronous commit). The size of the checkpoint
Mario Splivalo wrote:
Robert Haas wrote:
jura=# set enable_seqscan to false;
SET
jura=# explain analyze select * from transactions where
transaction_time_commit between '2008-01-01' and '2008-01-31 23:59:59';
QUERY PLAN
-
Robert Haas wrote:
On Fri, Feb 6, 2009 at 12:41 PM, Kevin Grittner
wrote:
Robert Haas wrote:
What's weird about this example is that when he sets enable_seqscan to
off, the bitmap index scan plan is actually substantially faster, even
though it in fact does scan nearly the entire heap. I don
Tom Lane wrote:
Hardly surprising --- a search on the index's lowest-order column would
require scanning practically all of the index. (If you think about the
ordering of the index entries you'll see why.) If this is a typical
query then you need a separate index on transaction_time_commit.
