On Thu, Nov 13, 2008 at 01:56:11PM +0100, Markus Wollny wrote:
> Sam Mason wrote:
> > You may have some luck with increasing the statistics target on the
> > entry_id and last_updated columns and re-ANALYZING the table. Then
> > again, the fact that it thinks it's only going to get a single row
>
Hi!
Sam Mason wrote:
> You may have some luck with increasing the statistics target on the
> entry_id and last_updated columns and re-ANALYZING the table. Then
> again, the fact that it thinks it's only going to get a single row
> back when it searches for the entity_id suggests that it's all a b
On Wed, Nov 12, 2008 at 04:15:23PM +0100, Markus Wollny wrote:
> I've got this simple query
>
> SELECT image_id
> FROM image_relation
> WHERE entity_id = 69560::integer
> ORDER BY last_updated DESC
> LIMIT1;
>
> which currently runs for something around 600ms. Here's the explain analyze
> o
Hi!
In preparation for my upcoming upgrade to PostgreSQL 8.3.5, I have taken the
opportunity to try this scenario on a test machine with the latest PostgreSQL
version. Unfortunately the result remains the same, though this database has
been just reloaded from a dump and vacuum analyzed. select
Hi!
We've got a table with the following definition:
CREATE TABLE image_relation
(
id integer,
article_id integer NOT NULL,
entity_id integer NOT NULL,
image_id integer NOT NULL,
subline text,
"position" integer,
article_headline text,
entity_name text,
entity_type_id integer,
