Hi all
I've have a strange problem with my Windows postgresql-9.0 service
stopping after any transaction which manipulates tables in any database
(Deleting records, Inserting records, bulk importing via \copy, etc). This
problem occurs regardless whether I'm accessing the database server via
p
Tobias Brox wrote:
> 13:19:13.840 - LOG: checkpoint complete
> 13:19:13.841 - LOG: checkpoint starting
> 13:20:43.176 - LOG: checkpoint complete
There wasn't a lot of time between the completion of one checkpoint
and the start of the next. And the two checkpoints finished a
minute and a
On 23 September 2010 22:55, Kevin Grittner wrote:
> Have you turned on checkpoint logging?
Yes ... it seems so:
13:19:13.840 - LOG: checkpoint complete: wrote 3849 buffers (0.2%); 0
transaction log file(s) added, 0 removed, 5 recycled; write=269.551 s,
sync=0.103 s, total=269.953 s
13:19:13.841
On 24/09/10 09:50, Tobias Brox wrote:
We've come to a tipping point with one of our database servers, it's
generally quite loaded but up until recently it was handling the load
well - but now we're seeing that it struggles to process all the
selects fast enough. Sometimes we're observing some we
We've come to a tipping point with one of our database servers, it's
generally quite loaded but up until recently it was handling the load
well - but now we're seeing that it struggles to process all the
selects fast enough. Sometimes we're observing some weird lock-like
behaviour (see my other po
Tobias Brox wrote:
> All while having this problem, there was one heavy query running
> in parallell ... not sure if that's relevant.
Have you turned on checkpoint logging? You might want to see if
these are happening at some particular point in the checkpoint
processing. If so, look through
On 15 September 2010 12:05, Tobias Brox wrote:
> Recently we've frequently encountered issues where some simple selects
> (meaning, selects doing an index lookup and fetching one row) have
> become stuck for several minutes. Apparently all requests on one
> exact table gets stuck, all requests no
On Thu, Sep 23, 2010 at 10:26 AM, Dmitry Teslenko wrote:
> Hello!
>
> I have this table:
>
> create table test (
> s1 varchar(255),
> s2 varchar(255),
> i1 integer,
> i2 integer,
>
> ... over 100 other fields
>
> );
>
> table contains over 8 million records
>
> there's
On Thu, Sep 23, 2010 at 7:51 AM, wrote:
> Not insulting, just amused bemusement. PG portrays itself as the best OS
> database, which it may well be. But it does so by stressing the
> row-by-agonizing-row approach to data. In other words, as just a record
> paradigm filestore for COBOL/java/
Dmitry Teslenko wrote:
> Seqscan is very slow and I want to avoid it. Subquery is very fast
> and i don't know why postgres chooses that plan.
>
> I know I can set enable_seqscan = off.
> Is there other ways to enforce index usage?
If you come at it from that angle, you probably won't get the
Hello!
I have this table:
create table test (
s1 varchar(255),
s2 varchar(255),
i1 integer,
i2 integer,
... over 100 other fields
);
table contains over 8 million records
there's these indexes:
create index is1 on test (s1);
create index is2 on test (s2);
crea
I can't tell if you meant for this to be insulting or my reading it that way is
wrong, but it certainly wasn't put in a helpful tone. Let me summarize for
you. You've been told that putting ORDER BY into a view is a generally poor
idea anyway, that it's better to find ways avoid this class of
>>> The question is how can we make it faster.
>>If there's just one region ID for any given postal code, you might try
>>adding a column to vehicleused and storing the postal codes there.
>>You could possibly populate that column using a trigger; probably it
>>doesn't change unless the postalcode
13 matches
Mail list logo
