I can't figure what is going on below; first of all, this count which
returns 1.5 million from a ~2 million row table:
woome=# explain analyze SELECT COUNT(*) FROM "webapp_person" WHERE
"webapp_person"."permissionflags" =
B''::"bit";
On Fri, Mar 20, 2009 at 8:47 PM, Frank Joerdens wrote:
> On Thu, Mar 12, 2009 at 1:38 PM, Frank Joerdens wrote:
>> On Thu, Mar 12, 2009 at 1:45 AM, Tom Lane wrote:
>> [...]
>>> You could try changing _IOLBF
>>> to _IOFBF near the head of postmaster/syslogger
On Fri, Mar 20, 2009 at 8:21 PM, Andrew Dunstan wrote:
>
>
> Frank Joerdens wrote:
>>
>> On Thu, Mar 12, 2009 at 1:38 PM, Frank Joerdens wrote:
>>
>>>
>>> On Thu, Mar 12, 2009 at 1:45 AM, Tom Lane wrote:
>>> [...]
>>>
>>
On Thu, Mar 12, 2009 at 1:38 PM, Frank Joerdens wrote:
> On Thu, Mar 12, 2009 at 1:45 AM, Tom Lane wrote:
> [...]
>> You could try changing _IOLBF
>> to _IOFBF near the head of postmaster/syslogger.c and see if that helps.
The patched server is now running on live, and we'
On Thu, Mar 12, 2009 at 9:32 PM, Laurent Laborde wrote:
> On Wed, Mar 11, 2009 at 11:42 PM, Frank Joerdens wrote:
>>
>> effective_cache_size = 4GB
>
> Only 4GB with 64GB of ram ?
I'd been overly cautious lately with config changes as it's been
diff
On Thu, Mar 12, 2009 at 1:45 AM, Tom Lane wrote:
[...]
> You could try changing _IOLBF
> to _IOFBF near the head of postmaster/syslogger.c and see if that helps.
I just put the patched .deb on staging and we'll give it a whirl there
for basic sanity checking - we currently have no way to even
app
On Wed, Mar 11, 2009 at 8:46 PM, Tom Lane wrote:
> Frank Joerdens writes:
>> Greetings. We're having trouble with full logging since we moved from
>> an 8-core server with 16 GB memory to a machine with double that
>> spec and I am wondering if this *should* be working
Greetings. We're having trouble with full logging since we moved from
an 8-core server with 16 GB memory to a machine with double that
spec and I am wondering if this *should* be working or if there is a
point on larger machines where logging and scheduling seeks of
background writes - or something
On Wed, Jan 7, 2009 at 3:23 AM, Tom Lane wrote:
> "Frank Joerdens" writes:
>> then I take the request size value from the error and do
>> echo 8810725376 > /proc/sys/kernel/shmmax
>> and get the same error again.
>
> What about shmall?
Yes that works, i
Tom Lane wrote:
> "Ryan Hansen" writes:
[...]
>> but when I set the shared buffer in PG and restart
>> the service, it fails if it's above about 8 GB.
>
> Fails how? And what PG version is that?
The thread seems to end here as far as the specific question was
concerned. I just ran into the same
On Tue, Aug 26, 2008 at 5:53 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Frank Joerdens" <[EMAIL PROTECTED]> writes:
>> It seems to me that the planner makes a very poor decision with this
>> particular query:
>
> Try increasing the stats on woouser. You
Eh, there was a spurious join in that query which was created by an
ORM which messed things up apparently. Sorry for the noise. This
abstracted version of the original query that does the same is fast:
woome=> EXPLAIN ANALYZE
SELECT *
FROM webapp_invite i
INNER JOIN webapp_person p ON (i.id = p.id
It seems to me that the planner makes a very poor decision with this
particular query:
--- snip ---
woome=> explain analyze SELECT "webapp_invite"."id",
"webapp_invite"."person_id", "webapp_invite"."session_id",
"webapp_invite"."created", "webapp_invite"."text",
"webapp_invite"."subject", "webapp_
On 6/26/08, Craig James <[EMAIL PROTECTED]> wrote:
> This seems like a bug to me, but it shows up as a performance problem.
> Since the column being queried is an integer, the second query (see below)
> can't possibly match, yet Postgres uses a typecast, forcing a full table
> scan for a value that
14 matches
Mail list logo
