On 10/24/2012 07:32 AM, gha...@gmail.com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 7620
> Logged by: Greg Hazel
> Email address: gha...@gmail.com
> PostgreSQL version: 9.2.1
> Operating system: Amazon Linux
> Description:
>
> array_
From the error info,
You might be able to try disable UAC. Then run the command in administrator
mode.
--
Thanks&Regards,
Xiong He
-- Original --
From: "henrique.assessoria";
Date: Fri, Oct 19, 2012 03:13 AM
To: "pgsql-bugs";
Subject
On Wed, Oct 24, 2012 at 2:21 AM, Craig Ringer wrote:
> On 10/24/2012 07:32 AM, gha...@gmail.com wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference: 7620
>> Logged by: Greg Hazel
>> Email address: gha...@gmail.com
>> PostgreSQL version: 9.2.1
>> Opera
I was chasing down a query that ran fine in 8.1 but had an near
infinite runtime in 9.2. It turned out to be from a bad filter
estimate that is surprisingly simple to reproduce:
postgres=# create table foo(i int);
CREATE TABLE
postgres=# insert into foo select 1000 + (v/200) from generate_series(
On Oct 23, 2012, at 6:03 PM, Merlin Moncure wrote:
> On Tue, Oct 23, 2012 at 6:32 PM, wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference: 7620
>> Logged by: Greg Hazel
>> Email address: gha...@gmail.com
>> PostgreSQL version: 9.2.1
>> Operating s
On Oct 24, 2012, at 12:21 AM, Craig Ringer wrote:
> On 10/24/2012 07:32 AM, gha...@gmail.com wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference: 7620
>> Logged by: Greg Hazel
>> Email address: gha...@gmail.com
>> PostgreSQL version: 9.2.1
>> Operat
On Oct 23, 2012, at 6:17 PM, Merlin Moncure wrote:
> On Tue, Oct 23, 2012 at 8:05 PM, Greg Hazel wrote:
>> On Oct 23, 2012, at 6:03 PM, Merlin Moncure wrote:
>>
>>> On Tue, Oct 23, 2012 at 6:32 PM, wrote:
The following bug has been logged on the website:
Bug reference: 7
On Wed, Oct 24, 2012 at 10:06 AM, Merlin Moncure wrote:
> I was chasing down a query that ran fine in 8.1 but had an near
> infinite runtime in 9.2. It turned out to be from a bad filter
> estimate that is surprisingly simple to reproduce:
Testing some more it turns out that this isn't really a
On Oct 24, 2012, at 12:21 AM, Craig Ringer wrote:
> On 10/24/2012 07:32 AM, gha...@gmail.com wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference: 7620
>> Logged by: Greg Hazel
>> Email address: gha...@gmail.com
>> PostgreSQL version: 9.2.1
>> Opera
Merlin Moncure writes:
> The following query runs fine: it estimates the returned rows pretty wel:
> postgres=# explain analyze select * from foo where i > 100 and i < 1;
> ...but if you introduce a floating point cast, it drastically changes
> the returned rows (why?):
> postgres=# explain
On Wed, Oct 24, 2012 at 2:26 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> The following query runs fine: it estimates the returned rows pretty wel:
>> postgres=# explain analyze select * from foo where i > 100 and i < 1;
>
>> ...but if you introduce a floating point cast, it drastically c
Merlin Moncure writes:
> Yeah -- I have a case where a large number of joins are happening that
> have a lot of filtering based on expressions and things like that.
Might be worth your while to install some indexes on those expressions,
if only to trigger collection of stats about them.
> I've b
On Wed, Oct 24, 2012 at 3:33 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> Yeah -- I have a case where a large number of joins are happening that
>> have a lot of filtering based on expressions and things like that.
>
> Might be worth your while to install some indexes on those expressions,
> i
On Wed, Oct 24, 2012 at 3:51 PM, Merlin Moncure wrote:
> On Wed, Oct 24, 2012 at 3:33 PM, Tom Lane wrote:
>> Merlin Moncure writes:
>>> Yeah -- I have a case where a large number of joins are happening that
>>> have a lot of filtering based on expressions and things like that.
>>
>> Might be wor
Tom Lane wrote:
> plus some not-very-large CPU-per-tuple charges
In my experience, cpu_tuple_cost should be higher. I've often had to
boost it to get good plans for a wide mix of queries in a load.
Doubling it to 0.02 is often not enough to get good plans. I've taken
it to 0.05 with production wo
15 matches
Mail list logo
