Обсуждение: How to uses self query plan
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
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?
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
Вложения
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.
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 > >
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
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.
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 .
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.