On Nov 22, 2007 6:44 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Are you examining only "trivial" queries? I've been able to identify a
> couple of new planner hotspots that could explain some slowdown if the
> planning time is material compared to the execution time. If you're
> seeing a slowdown on queries that run for awhile, that would be
> something else ...
Yes, I kept only queries with no join and a couple of where
conditions. As I explained previously, I can reproduce the behavior
with a single index scan on only one table (plan posted previously).
If anyone is interested I can post the content of this table (there's
nothing confidential in it so I should have the customer permission)
and a couple of instructions to reproduce the test case.
The case in which I used a few differents queries executes the
following ones directly extracted from the application (all are index
scans - and they use the exact same index on 8.2 and 8.3):
select libvil from vilsitelang where codelang='FRA' and codevil='LYO'
select TL.motsclesmetatags, TL.descriptifmeta, TL.motcleoverture_l,
TL.motcleoverture_c, TL.baselinetheme from themelang TL where
TL.codeth = 'ASS' and TL.codelang = 'FRA'
SELECT libvilpubwoo, codelang, codepays, petiteville FROM vilsite
WHERE codevil = 'LYO'
select libvil from vilsitelang where codelang='FRA' and codevil='LYO'
So as you can see, queries can't be simpler.
--
Guillaume
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
