From: | Vitalii Tymchyshyn <tivv00(at)gmail(dot)com> |
---|---|
To: | postgresql(at)foo(dot)me(dot)uk |
Cc: | postgres performance list <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Slow query: bitmap scan troubles |
Date: | 2012-12-04 18:50:41 |
Message-ID: | CABWW-d2gK6=AOBWxJij8GYS6CQC4+p7xWDsr4FSs2-BaXDQMsA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
Well, you don't need to put anything down. Most settings that change
planner decisions can be tuned on per-quey basis by issuing set commands in
given session. This should not affect other queries more than it is needed
to run query in the way planner chooses.
Best regards, Vitalii Tymchyshyn
2012/12/4 <postgresql(at)foo(dot)me(dot)uk>
>
> >> But the row estimates are not precise at the top of the join/filter.
> >> It thinks there will 2120 rows, but there are only 11.
>
> >Ah... I didn't spot that one...
>
> Yes, you are right there - this is probably a slightly atypical query of
> this sort actually, 2012 is a pretty good guess.
>
> On Claudio's suggestion I have found lots more things to read up on and am
> eagerly awaiting 6pm when I can bring the DB down and start tweaking. The
> effective_work_mem setting is going from 6Gb->88Gb which I think will make
> quite a difference.
>
> I still can't quite wrap around my head why accessing an index is expected
> to use more disk access than doing a bitmap scan of the table itself, but I
> guess it does make a bit of sense if postgres assumes the table is more
> likely to be cached.
>
> It's all quite, quite fascinating :)
>
> I'll let you know how it goes.
>
> - Phil
>
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
--
Best regards,
Vitalii Tymchyshyn
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2012-12-04 18:51:13 | Re: autovacuum truncate exclusive lock round two |
Previous Message | Claudio Freire | 2012-12-04 18:32:57 | Re: Slow query: bitmap scan troubles |
From | Date | Subject | |
---|---|---|---|
Next Message | postgresql | 2012-12-04 18:54:29 | Re: Slow query: bitmap scan troubles |
Previous Message | Claudio Freire | 2012-12-04 18:32:57 | Re: Slow query: bitmap scan troubles |