"Martijn van Oosterhout" <[EMAIL PROTECTED]> writes:
> On Fri, Nov 30, 2007 at 11:27:24AM -0500, Josh Harrison wrote:
>> Thanks for your reply
>> Is there a way to get them not to use the
>> heap for intermediate result and go to heap only for final data? This will
>> drastically improve the perfo
On Fri, Nov 30, 2007 at 11:27:24AM -0500, Josh Harrison wrote:
> Thanks for your reply
> Is there a way to get them not to use the
> heap for intermediate result and go to heap only for final data? This will
> drastically improve the performance but Im not sure if postgres can do that?
> Will creat
>
>
> Or using an IN or EXISTS query:
>
> SELECT person_id
> FROM person
> WHERE column1=1
> AND column2='62'
> AND person_id IN (
> SELECT person_id
> FROM person
> WHERE column1=1
>AND column2='189'
> )
>
> or
>
> SELECT person_id
> FROM person
"Martijn van Oosterhout" <[EMAIL PROTECTED]> writes:
> On Fri, Nov 30, 2007 at 08:21:18AM -0500, Josh Harrison wrote:
>> > > *Query1*
>> > > SELECT person_id FROM person WHERE (column1=1 AND column2='62')
>> > > INTERSECT
>> > > SELECT person_id FROM person WHERE (column1=1 AND column2='189')
>
>
> > > > *Query1*
> > > > SELECT person_id FROM person WHERE (column1=1 AND column2='62')
> > > > INTERSECT
> > > > SELECT person_id FROM person WHERE (column1=1 AND column2='189')
>
> > I get the same plan(see below) with 'sort' for 'intersect all'
> operation
> > too. Why is intersect n
On Fri, Nov 30, 2007 at 08:21:18AM -0500, Josh Harrison wrote:
> > > *Query1*
> > > SELECT person_id FROM person WHERE (column1=1 AND column2='62')
> > > INTERSECT
> > > SELECT person_id FROM person WHERE (column1=1 AND column2='189')
> I get the same plan(see below) with 'sort' for 'inters
On Nov 30, 2007 7:55 AM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Josh Harrison escribió:
>
> > Thanks...
> > I have 1 more question in the same line...
> >
> > *Query1*
> > SELECT person_id FROM person WHERE (column1=1 AND column2='62')
> > INTERSECT
> > SELECT person_id FROM person WHERE
Josh Harrison escribió:
> Thanks...
> I have 1 more question in the same line...
>
> *Query1*
> SELECT person_id FROM person WHERE (column1=1 AND column2='62')
> INTERSECT
> SELECT person_id FROM person WHERE (column1=1 AND column2='189')
Hmm, I think INTERSECT (and EXCEPT) is pretty stupid
On Nov 29, 2007 8:15 AM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Josh Harrison escribió:
> > >
> > > > For example if I have a table Person with 3 fields
> (name,city_id,age).
> > > And
> > > > the table contains 1000 rows. The table has 2 indexes city_id and
> age
> > > > If I have a query :
Josh Harrison escribió:
> >
> > > For example if I have a table Person with 3 fields (name,city_id,age).
> > And
> > > the table contains 1000 rows. The table has 2 indexes city_id and age
> > > If I have a query :
> > > SELECT * FROM PERSON WHERE city_id=5 AND AGE=30
>
> OkaySo If I have a que
>
> > For example if I have a table Person with 3 fields (name,city_id,age).
> And
> > the table contains 1000 rows. The table has 2 indexes city_id and age
> > If I have a query :
> > SELECT * FROM PERSON WHERE city_id=5 AND AGE=30
>
> The answer is "it depends". Postgres has a cost based planner,
Please always CC the list so other people can respond.
On Wed, Nov 28, 2007 at 10:21:39PM -0500, Josh Harrison wrote:
> > It isn't the recheck that's costing it, it's probably just that you're
> > matching a lot of rows. A bitmap scan classically needs a recheck
> > because if a lot of rows need t
On Wed, Nov 28, 2007 at 02:20:11PM -0500, Josh Harrison wrote:
> >Some indexes are inexact, i.e. they may sometimes return tuples that
> >don't actually match the index condition.
>
> What causes an index to be inexact. When you create an index and vacuum it
> regularly, it is suppose to be correc
>Some indexes are inexact, i.e. they may sometimes return tuples that
>don't actually match the index condition.
What causes an index to be inexact. When you create an index and vacuum it
regularly, it is suppose to be correctright??
>This also happens with bitmap
>scans, because it'll return
On Wed, Nov 28, 2007 at 01:18:56PM -0500, Josh Harrison wrote:
> Hi,
> Sorry if my question is silly.
> When I use explain analyze command I come across 'recheck condition' in some
> places.
> I googled for this but didn't get any solid answers.
Some indexes are inexact, i.e. they may sometimes r
15 matches
Mail list logo