Hello,

My purpose is to uses different query plan depending on queries
I got the following problem : some queries are taking too much time and
postgresql does not take the most relevant index in account.
I search on internet and found that no HINT function was available in
postgresl.
I tried to change indexes parameters in postgresql.conf but eache time I
set a param to OFF (example nested_loop ,seqscan, ...) , some queries
freeze database .

How can we force postgresql to use a plan ?

olivier

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On Dec 18, 2007 4:21 PM, olivier.boissard@cerene.fr
<olivier.boissard@cerene.fr> wrote:
> Hello,
>
> My purpose is to uses different query plan depending on queries
> I got the following problem : some queries are taking too much time and
> postgresql does not take the most relevant index in account.
> I search on internet and found that no HINT function was available in
> postgresl.
> I tried to change indexes parameters in postgresql.conf but eache time I
> set a param to OFF (example nested_loop ,seqscan, ...) , some queries
> freeze database .
>
> How can we force postgresql to use a plan ?

That's not how we do things in postgresql land (usually).

You should figure out WHY your queries are picking the wrong plan, and
then see if you can get them to pick the right ones. If it's a query
planner bug, you report it here, or the perform or general lists, and
it gets fixed. Generic hints aren't likely to happen any time soon,
although I do believe 8.3 is introducing function costing of some
kind, which seems like a useful idea.

But, back to fixing your slow queries.

1: Increase statistics targets on the guilty columns and reanalyze.
2: Run explain analyze select.... and post the output here.
3: ???
4: profit?

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Scott Marlowe a écrit :
> On Dec 18, 2007 4:21 PM, olivier.boissard@cerene.fr
> <olivier.boissard@cerene.fr> wrote:
>
>> Hello,
>>
>> My purpose is to uses different query plan depending on queries
>> I got the following problem : some queries are taking too much time and
>> postgresql does not take the most relevant index in account.
>> I search on internet and found that no HINT function was available in
>> postgresl.
>> I tried to change indexes parameters in postgresql.conf but eache time I
>> set a param to OFF (example nested_loop ,seqscan, ...) , some queries
>> freeze database .
>>
>> How can we force postgresql to use a plan ?
>>
>
> That's not how we do things in postgresql land (usually).
>
> You should figure out WHY your queries are picking the wrong plan, and
> then see if you can get them to pick the right ones. If it's a query
> planner bug, you report it here, or the perform or general lists, and
> it gets fixed. Generic hints aren't likely to happen any time soon,
> although I do believe 8.3 is introducing function costing of some
> kind, which seems like a useful idea.
>
> But, back to fixing your slow queries.
>
> 1: Increase statistics targets on the guilty columns and reanalyze.
> 2: Run explain analyze select.... and post the output here.
> 3: ???
> 4: profit?
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at
>
> http://www.postgresql.org/about/donate
>
>
Thanks for reply

I will extract some queries.
I want to precise that I use postgresql 8.1.0 .

Olivier




---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On Dec 19, 2007 1:57 AM, olivier boissard <olivier.boissard@cerene.fr> wrote:
> Scott Marlowe a écrit :
>
> > On Dec 18, 2007 4:21 PM, olivier.boissard@cerene.fr
> > <olivier.boissard@cerene.fr> wrote:
> >
> >> Hello,
> >>
> >> My purpose is to uses different query plan depending on queries
> >> I got the following problem : some queries are taking too much time and
> >> postgresql does not take the most relevant index in account.
> >> I search on internet and found that no HINT function was available in
> >> postgresl.
> >> I tried to change indexes parameters in postgresql.conf but eache timeI
> >> set a param to OFF (example nested_loop ,seqscan, ...) , some queries
> >> freeze database .
> >>
> >> How can we force postgresql to use a plan ?
> >>
> >
> > That's not how we do things in postgresql land (usually).
> >
> > You should figure out WHY your queries are picking the wrong plan, and
> > then see if you can get them to pick the right ones. If it's a query
> > planner bug, you report it here, or the perform or general lists, and
> > it gets fixed. Generic hints aren't likely to happen any time soon,
> > although I do believe 8.3 is introducing function costing of some
> > kind, which seems like a useful idea.
> >
> > But, back to fixing your slow queries.
> >
> > 1: Increase statistics targets on the guilty columns and reanalyze.
> > 2: Run explain analyze select.... and post the output here.
> > 3: ???
> > 4: profit?
> >
> Thanks for reply
>
> I will extract some queries.
> I want to precise that I use postgresql 8.1.0 .

First step would be to update to the latest 8.1.x version, whatever
that is. There have been a LOT of fixes in the 8.1 branch since 8.1.0
came out, and one might be a fix for your query problem. minor
updates are strictly bug and security fixes, so they're not likely to
cause any problems.

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

You're right .
I will begin by migrate postgresql version.
postgresql is now to 8.3 version . A lot of performance inprovements
have been made in this last version .
In any case I must do a pg_dump/pg_restore.
So , Should I try directly 8.3 version or is it more cautious to stay in
8.1.x version ?


Olivier


Scott Marlowe a écrit :
> On Dec 19, 2007 1:57 AM, olivier boissard <olivier.boissard@cerene.fr> wrote:
>
>> Scott Marlowe a écrit :
>>
>>
>>> On Dec 18, 2007 4:21 PM, olivier.boissard@cerene.fr
>>> <olivier.boissard@cerene.fr> wrote:
>>>
>>>
>>>> Hello,
>>>>
>>>> My purpose is to uses different query plan depending on queries
>>>> I got the following problem : some queries are taking too much time and
>>>> postgresql does not take the most relevant index in account.
>>>> I search on internet and found that no HINT function was available in
>>>> postgresl.
>>>> I tried to change indexes parameters in postgresql.conf but eache time I
>>>> set a param to OFF (example nested_loop ,seqscan, ...) , some queries
>>>> freeze database .
>>>>
>>>> How can we force postgresql to use a plan ?
>>>>
>>>>
>>> That's not how we do things in postgresql land (usually).
>>>
>>> You should figure out WHY your queries are picking the wrong plan, and
>>> then see if you can get them to pick the right ones. If it's a query
>>> planner bug, you report it here, or the perform or general lists, and
>>> it gets fixed. Generic hints aren't likely to happen any time soon,
>>> although I do believe 8.3 is introducing function costing of some
>>> kind, which seems like a useful idea.
>>>
>>> But, back to fixing your slow queries.
>>>
>>> 1: Increase statistics targets on the guilty columns and reanalyze.
>>> 2: Run explain analyze select.... and post the output here.
>>> 3: ???
>>> 4: profit?
>>>
>>>
>> Thanks for reply
>>
>> I will extract some queries.
>> I want to precise that I use postgresql 8.1.0 .
>>
>
> First step would be to update to the latest 8.1.x version, whatever
> that is. There have been a LOT of fixes in the 8.1 branch since 8.1.0
> came out, and one might be a fix for your query problem. minor
> updates are strictly bug and security fixes, so they're not likely to
> cause any problems.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>
>


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

olivier.boissard@cerene.fr wrote:
> You're right .
> I will begin by migrate postgresql version.
> postgresql is now to 8.3 version . A lot of performance inprovements
> have been made in this last version .
> In any case I must do a pg_dump/pg_restore.
> So , Should I try directly 8.3 version or is it more cautious to stay in
> 8.1.x version ?
>

It mostly depends on you. PostgreSQL 8.3 is still in beta phase. So, if
you're also on development stage, you can use 8.3. Otherwise, it's
better to use the latest stable available, which means 8.2.5.


--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Dec 19, 2007 4:23 PM, olivier.boissard@cerene.fr
<olivier.boissard@cerene.fr> wrote:
> You're right .
> I will begin by migrate postgresql version.
> postgresql is now to 8.3 version . A lot of performance inprovements
> have been made in this last version .
> In any case I must do a pg_dump/pg_restore.
> So , Should I try directly 8.3 version or is it more cautious to stay in
> 8.1.x version ?

No, not what I meant! I meant to go to the latest 8.1 version. i.e.
8.1.0 has lots of bugs that 8.1.10 (or whatever the latest 8.1 is) has
fixed. If you wanna migrate to 8.2.5 that would probably be ok, but
8.3 isn't quite done yet.

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Guillaume Lelarge a écrit :
> olivier.boissard@cerene.fr wrote:
>
>> You're right .
>> I will begin by migrate postgresql version.
>> postgresql is now to 8.3 version . A lot of performance inprovements
>> have been made in this last version .
>> In any case I must do a pg_dump/pg_restore.
>> So , Should I try directly 8.3 version or is it more cautious to stay in
>> 8.1.x version ?
>>
>>
>
> It mostly depends on you. PostgreSQL 8.3 is still in beta phase. So, if
> you're also on development stage, you can use 8.3. Otherwise, it's
> better to use the latest stable available, which means 8.2.5.
>
>
>
I want in fact to make test on a server before , when validated migrate
on production server , so 8.2.5 is more appropriate.
Will I be able to keep my postgresql.conf file or is it not compatible ?


Olivier
..

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On Dec 19, 2007 5:17 PM, olivier.boissard@cerene.fr
<olivier.boissard@cerene.fr> wrote:
> Guillaume Lelarge a écrit :
> > olivier.boissard@cerene.fr wrote:
> >
> >> You're right .
> >> I will begin by migrate postgresql version.
> >> postgresql is now to 8.3 version . A lot of performance inprovements
> >> have been made in this last version .
> >> In any case I must do a pg_dump/pg_restore.
> >> So , Should I try directly 8.3 version or is it more cautious to stay in
> >> 8.1.x version ?
> >>
> >>
> >
> > It mostly depends on you. PostgreSQL 8.3 is still in beta phase. So, if
> > you're also on development stage, you can use 8.3. Otherwise, it's
> > better to use the latest stable available, which means 8.2.5.
> >
> >
> >
> I want in fact to make test on a server before , when validated migrate
> on production server , so 8.2.5 is more appropriate.
> Will I be able to keep my postgresql.conf file or is it not compatible ?

No, you'll need to edit the new one by hand to reflect the changes
you've made in the old one. Some things get renamed from one to the
next, and often newer versions of pgsql have new settings you that the
old version's postgresql.conf wouldn't know about.

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate