I'm encountering an issue where PG 9.2.4 (we also see this with 9.2.3)
is picking a plan involving a bitmap heap scan that turns out to be much
slower than a nested-loop plan using indexes.
The planner picks the hashjoin plan by default (see attached files)
Bitmap Heap Scan on public.table_b_2
On Wed, Apr 10, 2013 at 09:49:55AM -0400, Steve Singer wrote:
> I'm encountering an issue where PG 9.2.4 (we also see this with
> 9.2.3) is picking a plan involving a bitmap heap scan that turns out
> to be much slower than a nested-loop plan using indexes.
>
> The planner picks the hashjoin plan
On 13-04-10 09:56 AM, k...@rice.edu wrote:
On Wed, Apr 10, 2013 at 09:49:55AM -0400, Steve Singer wrote:
Hi Steve,
The one thing that stands out to me is that you are working with 200GB of
data on a machine with 4-8GB of ram and you have the random_page_cost set
to 2.0. That is almost comple
On Wed, Apr 10, 2013 at 11:56:32AM -0400, Steve Singer wrote:
> On 13-04-10 09:56 AM, k...@rice.edu wrote:
> >On Wed, Apr 10, 2013 at 09:49:55AM -0400, Steve Singer wrote:
>
> >
> >Hi Steve,
> >
> >The one thing that stands out to me is that you are working with 200GB of
> >data on a machine with
On Wed, Apr 10, 2013 at 6:49 AM, Steve Singer wrote:
> I'm encountering an issue where PG 9.2.4 (we also see this with 9.2.3) is
> picking a plan involving a bitmap heap scan that turns out to be much
> slower than a nested-loop plan using indexes.
>
> The planner picks the hashjoin plan by defaul
On Wed, Apr 10, 2013 at 8:56 AM, Steve Singer wrote:
> On 13-04-10 09:56 AM, k...@rice.edu wrote:
>
>> On Wed, Apr 10, 2013 at 09:49:55AM -0400, Steve Singer wrote:
>>
>
>
>> Hi Steve,
>>
>> The one thing that stands out to me is that you are working with 200GB of
>> data on a machine with 4-8GB o
Afternoon
So I just realized I've been just reimporting me Postgres configs from one
version to the next, since they were initially customized for my setup.
Maybe from 7.x... And now on 9.2.4
Is there an easy/clean way to adapt my old config file to the new stuff,
I'm not sure what all has chang
On 04/10/2013 04:25 PM, Tory M Blue wrote:
Is there an easy/clean way to adapt my old config file to the new stuff,
I'm not sure what all has changed, so wondering if I just have to go
line by line and somehow consolidate old to new, area there any tools or
mechanism to do so?
Ehhh, at that po
On Wed, Apr 10, 2013 at 2:42 PM, Shaun Thomas wrote:
> On 04/10/2013 04:25 PM, Tory M Blue wrote:
>
> Is there an easy/clean way to adapt my old config file to the new stuff,
>> I'm not sure what all has changed, so wondering if I just have to go
>> line by line and somehow consolidate old to new
Hi,
Could some please explain what these warnings mean in postgres.
I see these messages a lot when automatic vacuum runs.
1 tm:2013-04-10 11:39:20.074 UTC db: pid:13766 LOG: automatic vacuum
of table "DB1.nic.pvxt": could not (re)acquire exclusive lock for truncate
scan
1 tm:2013-04
Hi Bambi,
Thank you the prompt reply.
This table is very volatile, lot of inserts/updates happen on this
tables(atleast 20~30 inserts/min).
When auto vacuum tries to run on this table, I get this warning.
Is there a way, I force it to happen, because the table/indexes statistics
are becoming sta
On 13-04-10 02:06 PM, Jeff Janes wrote:
On Wed, Apr 10, 2013 at 6:49 AM, Steve Singer mailto:ssin...@ca.afilias.info>> wrote:
I think the index recheck means your bitmap is overflowing (i.e. needing
more space than work_mem) and so keeping only the pages which have at
least one match, which m
12 matches
Mail list logo
