Skip site navigation (1) Skip section navigation (2)

Re: What is the best way to do attribute/values?

From: Mark Kirkwood <markir(at)coretech(dot)co(dot)nz>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Daniel Ceregatti <vi(at)sh(dot)nu>, pgsql-performance(at)postgresql(dot)org
Subject: Re: What is the best way to do attribute/values?
Date: 2004-08-25 08:22:18
Message-ID: 412C4C3A.2030001@coretech.co.nz (view raw or flat)
Thread:
Lists: pgsql-performance

Josh Berkus wrote:

> Things we've already tried to avoid going over old ground:
>
>1) increasing statistics;
>2) increasing sort_mem (to 256MB, which is overkill)
>3) testing on 8.0 beta, which does not affect the issue.
>
>At this point I'm looking for ideas.   Suggestions, anyone?
>
>  
>
with respect to query design:

consider instead of:

select
	pav1.person_id
from
	person_attributes_vertical pav1,
	person_attributes_vertical pav2
where
	pav1.attribute_id = 1
	and pav1.value_id in (2,3)
	and pav2.attribute_id = 2
	and pav2.value_id in (2,3)
	and pav1.person_id = pav2.person_id

try:

select
	pav1.person_id
from
	person_attributes_vertical pav1
where
	   (    pav1.attribute_id = 1
	    and pav1.value_id in (2,3))
	or (    pav1.attribute_id = 2
	    and pav1.value_id in (2,3))
	
I am gambling that the 'or's' might be less expensive than the multiple self joins (particularly in the more general cases!).

To make access work well you might want to have *several* concatenated indexes of 2 -> 4 attributes - to work around Pg inability to use more than 1 in a given query.
For this query indexing (attribute_id, value_id) is probably good.

Consider playing with 'random_page_cost' and maybe 'effective_cache_size' to encourage the planner to use 'em.

regards

Mark





In response to

Responses

pgsql-performance by date

Next:From: Jan WieckDate: 2004-08-25 11:03:13
Subject: Re: postgresql performance with multimedia
Previous:From: Gregory S. WilliamsonDate: 2004-08-25 07:14:01
Subject: Re: postgresql performance with multimedia

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group