I don't know why seq scan is running on the following query where the same
query is giving index scan on other servers:
explain analyze
select *
from act
where act.acttype in ( 'Meeting','Call','Task');
QUERY PLAN
---
On Oct 12, 2010, at 11:58 AM, Tom Lane wrote:
> Jesper Krogh writes:
>> On 2010-10-12 19:07, Tom Lane wrote:
>>> Anyway, if anyone is hot to make COUNT(*) faster, that's where to look.
>
>> Just having 32 bytes bytes of "payload" would more or less double
>> you time to count if I read you test
On Wed, Oct 20, 2010 at 8:25 PM, Joshua D. Drake wrote:
> On Wed, 2010-10-20 at 22:13 -0400, Bruce Momjian wrote:
>> Ben Chobot wrote:
>> > On Oct 7, 2010, at 4:38 PM, Steve Crawford wrote:
>> >
>> > > I'm weighing options for a new server. In addition to PostgreSQL, this
>> > > machine will hand
bricklen wrote:
> On Sat, Oct 9, 2010 at 4:26 PM, Neil Whelchel wrote:
> > Maybe an
> > estimate(*) that works like count but gives an answer from the index without
> > checking visibility? I am sure that this would be good enough to make a page
> > list, it is really no big deal if it errors on t
Dimi Paun wrote:
Sorry, it wasn't a ps output, it was a line from top(1).
My to header says:
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
23425 postgres 20
On Wed, 2010-10-20 at 22:13 -0400, Bruce Momjian wrote:
> Ben Chobot wrote:
> > On Oct 7, 2010, at 4:38 PM, Steve Crawford wrote:
> >
> > > I'm weighing options for a new server. In addition to PostgreSQL, this
> > > machine will handle some modest Samba and Rsync load.
> > >
> > > I will have en
Ben Chobot wrote:
> On Oct 7, 2010, at 4:38 PM, Steve Crawford wrote:
>
> > I'm weighing options for a new server. In addition to PostgreSQL, this
> > machine will handle some modest Samba and Rsync load.
> >
> > I will have enough RAM so the virtually all disk-read activity will be
> > cached.
On Wed, Oct 20, 2010 at 3:47 PM, Scott Marlowe wrote:
> Or use htop. it identifies all the basic postgresql processes by job,
> like logger process, writer process and so on.
FYI, htop is available from the epel repo.
--
To understand recursion, one must first understand recursion.
--
Sent vi
On Wed, Oct 20, 2010 at 2:57 PM, Tom Lane wrote:
> Dimi Paun writes:
>> On Wed, 2010-10-20 at 16:45 -0400, Tom Lane wrote:
>>> Hm, what ps options did you use? I'm having a hard time reproducing
>>> your display format on Fedora 13 (procps-3.2.8-7.fc13.x86_64).
>
>> Sorry, it wasn't a ps output,
Dimi Paun writes:
> On Wed, 2010-10-20 at 16:45 -0400, Tom Lane wrote:
>> Hm, what ps options did you use? I'm having a hard time reproducing
>> your display format on Fedora 13 (procps-3.2.8-7.fc13.x86_64).
> Sorry, it wasn't a ps output, it was a line from top(1).
Oh, yeah, top typically does
On Wed, 2010-10-20 at 16:45 -0400, Tom Lane wrote:
> Hm, what ps options did you use? I'm having a hard time reproducing
> your display format on Fedora 13 (procps-3.2.8-7.fc13.x86_64).
Sorry, it wasn't a ps output, it was a line from top(1).
My to header says:
PID USER PR NI VIRT RES
Dimi Paun writes:
> On Wed, 2010-10-20 at 16:26 -0400, Tom Lane wrote:
>> It's probably a backend process, not the postmaster --- I suspect the
>> OP is using a version of ps that only tells you the original process
>> name by default.
> I'm running CentOS 5.5, using procps-3.2.7-16.el5.
Hm, wha
On Wed, 2010-10-20 at 16:26 -0400, Tom Lane wrote:
> > It seems strange that the postmaster is eating 99% cpu. Is there a
> > chance that it's flooded with connection attempts?
Maybe, I'll try to figure that one out next time it happens.
> It's probably a backend process, not the postmaster --- I
Dimi Paun wrote:
Folks,
I am running into a problem with the postmaster: from time to time, it
runs for a long time. E.g., from top:
23425 postgres 20 0 22008 10m 10m R 99.9 0.5 21:45.87 postmaster
I'd like to figure out what it is doing. How can I figure out what
statement causes the p
Jeff Davis writes:
> On Wed, 2010-10-20 at 14:44 -0400, Dimi Paun wrote:
>> 23425 postgres 20 0 22008 10m 10m R 99.9 0.5 21:45.87 postmaster
>>
>> I'd like to figure out what it is doing. How can I figure out what
>> statement causes the problem?
> It seems strange that the postmaster is
On Wed, 2010-10-20 at 14:44 -0400, Dimi Paun wrote:
> 23425 postgres 20 0 22008 10m 10m R 99.9 0.5 21:45.87 postmaster
>
> I'd like to figure out what it is doing. How can I figure out what
> statement causes the problem?
>
It seems strange that the postmaster is eating 99% cpu. Is there
On Wed, 2010-10-20 at 15:24 -0400, Reid Thompson wrote:
> This is controlled by settings in the postgresql.conf file.
> see the appropriate doc pagevv for your version
> http://www.postgresql.org/docs/8.2/static/runtime-config-logging.html
Thanks for the link Reid, this seems to be doing what
On Wed, 2010-10-20 at 14:44 -0400, Dimi Paun wrote:
> Folks,
> is there a way I can log all SQL statements to a file, together with the
> time it took to execute them?
>
> --
> Dimi Paun
> Lattica, Inc.
This is controlled by settings in the postgresql.conf file.
see the appropriate doc page
Folks,
I am running into a problem with the postmaster: from time to time, it
runs for a long time. E.g., from top:
23425 postgres 20 0 22008 10m 10m R 99.9 0.5 21:45.87 postmaster
I'd like to figure out what it is doing. How can I figure out what
statement causes the problem?
is there
19 matches
Mail list logo
