Scott Marlowe a écrit :
> On 10/17/07, Stéphane Schildknecht
> <[EMAIL PROTECTED]> wrote:
>
>> Tom Lane a écrit :
>>
>> Yes, I am. The command line is (in a shell script whom ouput is
>> redirected in a global file) :
>>
>> vacuumdb -d $DBNAME -p $DBPORT -U $DBUSR -z -v
>>
>>
>> That does not ex
Tom Lane a écrit :
> =?ISO-8859-1?Q?St=E9phane_Schildknecht?= <[EMAIL PROTECTED]> writes:
>
>> Yes, I am. The command line is (in a shell script whom ouput is
>> redirected in a global file) :
>>
>
>
>> vacuumdb -d $DBNAME -p $DBPORT -U $DBUSR -z -v
>>
>
>
>> That does not expl
I remember when I was using SQL server we did like like that:
SELECT count(CASE WHEN A THEN 1 END) AS cnt_a, count(CASE WHEN B
THEN 1 END) AS cnt_b FROM tab WHERE C;
I did a little test with pg_bench data, also works in PostgreSQL:
test=# select count(*) from history where tid = 1;
count
---
On Wed, 2007-10-10 at 19:49 -0500, Scott Marlowe wrote:
> On 10/10/07, Radhika S <[EMAIL PROTECTED]> wrote:
> > Thank you scott.
> >
> > We plan on upgrading to Postgres 8.2 very soon.
> > Would it be safe to say I can make my SHARED BUFFER setting 200MB (I have
> > 2GB memory ).
> > The default i
Chris Kratz <[EMAIL PROTECTED]> writes:
> On Wednesday 17 October 2007 14:49, Tom Lane wrote:
>> Evidently it's not realizing that every row of par will have a join
>> partner, but why not? I suppose a.activityid is unique, and in most
>> cases that I've seen the code seems to get that case right.
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> henk de wit escribió:
>>> How is the memory consumed? How are you measuring it? I assume you
>>> mean the postgres process that is running the query uses the memory.
>>> If so, which tool(s) are you using and what's the output that shows it
>>> being us
henk de wit escribió:
> > How is the memory consumed? How are you measuring it? I assume you
> > mean the postgres process that is running the query uses the memory.
> > If so, which tool(s) are you using and what's the output that shows it
> > being used?
>
> It's periodically measured and recor
On Wednesday 17 October 2007 14:49, Tom Lane wrote:
> Chris Kratz <[EMAIL PROTECTED]> writes:
> > I'm struggling to get postgres to run a particular query quickly.
>
> The key problem seems to be the join size misestimate here:
> >-> Hash Join (cost=45.92..1251.07 rows=21 width=8
Chris Kratz <[EMAIL PROTECTED]> writes:
> I'm struggling to get postgres to run a particular query quickly.
The key problem seems to be the join size misestimate here:
>-> Hash Join (cost=45.92..1251.07 rows=21 width=8) (actual
> time=0.948..10.439 rows=1199 loops=1)
>
On 10/17/07, Stéphane Schildknecht
<[EMAIL PROTECTED]> wrote:
> Tom Lane a écrit :
>
> Yes, I am. The command line is (in a shell script whom ouput is
> redirected in a global file) :
>
> vacuumdb -d $DBNAME -p $DBPORT -U $DBUSR -z -v
>
>
> That does not explain why we don't get FSM statitics displ
Hello Everyone,
I'm struggling to get postgres to run a particular query quickly. It seems
that very early on, the planner seems to mis-estimate the number of rows
returned by a join which causes it to assume that there is only 1 row as it
goes up the tree. It then picks a nested loop join wh
Stefano Dal Pra escribió:
> Your first post says vacuum goes worse (slower).
> I see that you do not issue the -f option (FULL VACUUM).
>
> I had a similar situation with a server (with frequent update)
> performing nightly vacuumdb. After a few many days it went
> slower and slower.
When you hav
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> What would be really useful is to remove all that noise from vacuum and
> make it appear on a view.
Well, if you want something decoupled from VACUUM there's already
contrib/pg_freespacemap.
> 8.4 material all of this, of course.
I am hoping that we r
=?ISO-8859-1?Q?St=E9phane_Schildknecht?= <[EMAIL PROTECTED]> writes:
> Yes, I am. The command line is (in a shell script whom ouput is
> redirected in a global file) :
> vacuumdb -d $DBNAME -p $DBPORT -U $DBUSR -z -v
> That does not explain why we don't get FSM statitics display.
Is $DBUSR a su
Your first post says vacuum goes worse (slower).
I see that you do not issue the -f option (FULL VACUUM).
I had a similar situation with a server (with frequent update)
performing nightly vacuumdb. After a few many days it went
slower and slower.
The first solution was to add the -f switch.
Note
Joshua D. Drake wrote:
> On Tue, 16 Oct 2007 17:03:39 -0700 (PDT)
> Brian Herlihy <[EMAIL PROTECTED]> wrote:
>
> > Would it make sense to show the FSM stats for individual table
> > vaccums as well? I'm wondering if the reason they aren't shown is
> > because it wouldn't be useful or isn't practi
Steinar H. Gunderson wrote:
> On Wed, Oct 17, 2007 at 02:30:52PM +0200, Stefano Dal Pra wrote:
>> The main goal would be to get multiple results while scanning the
>> table[s] once only
>> thus getting results in a faster way.
>
> In 8.3, Postgres will do this for you itself -- if you already hav
On 10/17/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> Stefano Dal Pra wrote:
> > suppose you have a large table tab and two (or more) queryes like this:
> >
> > SELECT count(*),A FROM tab WHERE C GROUP BY A;
> > SELECT count(*),B FROM tab WHERE C GROUP BY B;
> >
> > is there any way to get b
On Wed, Oct 17, 2007 at 02:30:52PM +0200, Stefano Dal Pra wrote:
> The main goal would be to get multiple results while scanning the
> table[s] once only
> thus getting results in a faster way.
In 8.3, Postgres will do this for you itself -- if you already have a
sequential scan running against a
Stefano Dal Pra wrote:
> suppose you have a large table tab and two (or more) queryes like this:
>
> SELECT count(*),A FROM tab WHERE C GROUP BY A;
> SELECT count(*),B FROM tab WHERE C GROUP BY B;
>
> is there any way to get both results in a single query,
> eventually through stored procedure?
>
Hi everybody,
suppose you have a large table tab and two (or more) queryes like this:
SELECT count(*),A FROM tab WHERE C GROUP BY A;
SELECT count(*),B FROM tab WHERE C GROUP BY B;
is there any way to get both results in a single query,
eventually through stored procedure?
The retrieved [count(*)
Tom Lane a écrit :
> "Scott Marlowe" <[EMAIL PROTECTED]> writes:
>
>> On 10/16/07, St=E9phane Schildknecht
>> <[EMAIL PROTECTED]> wrote:
>>
>>> That's also why I am so disappointed vacuum doesn't give me these 4
>>> hints lines.
>>>
>
>
>> What kind of error, or output, does it gi
22 matches
Mail list logo
