Gary Warner writes:
> Recently my database stopped respecting one of my indexes, which took a query
> that should run in "subsecond response time" and turning it into something
> that with small data sets runs in the 7-10 minute range and with large data
> sets runs in the 30 minute - eternity
Can you post your non-default postgresql.conf settings? (I'd hazard a
guess that you have effective_cache_size set to the default 128MB).
Best wishes
Mark
On 24/11/11 11:24, Gary Warner wrote:
Very Fast Version:
Recently my database stopped respecting one of my indexes, which took a query th
On Wed, Nov 23, 2011 at 7:24 PM, Gary Warner wrote:
> See that "Seq Scan on link_url"? We can't figure out why that is there! We
> should be scanning for a matching "urlid" and we have an index on "urlid"?
>
> When this is happening in a "two table" version of this problem, we can get
> tempor
Very Fast Version:
Recently my database stopped respecting one of my indexes, which took a query
that should run in "subsecond response time" and turning it into something that
with small data sets runs in the 7-10 minute range and with large data sets
runs in the 30 minute - eternity range.
E
On 11/21/2011 04:03 PM, Christiaan Willemsen wrote:
Secondly, I also looked at the reliability figures of the Intel 320.
They show 5 years of 20GB per day, meaning that it will hold up for
about 200 days in our system. RAID 10 wil make 400 days of that, but
this seems hardly a lot.. Am I miss
On Tue, Nov 22, 2011 at 11:41 PM, Bruce Momjian wrote:
> Amitabh Kant wrote:> >
> >
> > On a slightly unrelated note, you had once (
> > http://archives.postgresql.org/pgsql-general/2011-08/msg00944.php) said
> to
> > limit shared_buffers max to 8 GB on Linux and leave the rest for OS
> > caching
