Re: issue related to logging facility of postgres

On Wed, Jul 27, 2011 at 5:11 AM, shailesh singh <shaileshjuly <at> gmail.com> wrote:
> I want to configure Logging of postgres in such a way that messages of
> different severity should be logged in different log file. eg: all ERROR
> message should be written in error-msg.log file while all NOTICE mesage
> should be written in notice-msg.log file.
>
> In order to do that what changes should i need to do in configuration file ?
> Could you pl give a solution.

There's no such facility built-in.  You might want to do something
like "log everything in CSV format, and then run a  Perl script over
it afterwards to split it up".

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--

-- 
Sent via pgsql-performance mailing list (pgsql-performance <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: issue related to logging facility of postgres

Syslog does that, I believe. Have a look at the man page for syslog.conf.

On Wed, Jul 27, 2011 at 5:11 AM, shailesh singh <shaileshjuly <at> gmail.com> wrote:
> Hi,
> I want to configure Logging of postgres in such a way that messages of
> different severity should be logged in different log file. eg: all ERROR
> message should be written in error-msg.log file while all NOTICE mesage
> should be written in notice-msg.log file.
>
> In order to do that what changes should i need to do in configuration file ?
> Could you pl give a solution.
>
> --
>   With Regards,
>   Shailesh Singh
>
>
>

--

-- 
Sent via pgsql-performance mailing list (pgsql-performance <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: 8.4 optimization regression?

I wrote:
> Mark Kirkwood <mark.kirkwood <at> catalyst.net.nz> writes:
>> [ assorted examples showing that commit
>> 7f3eba30c9d622d1981b1368f2d79ba0999cdff2 has got problems ]

> ...
> So, not only are you correct that we should revert the changes to
> eqjoinsel_inner, but what's happening in eqjoinsel_semi is wrong too.

I've retested these examples with the patches I committed yesterday.
Six of the eight examples are estimated pretty nearly dead on, while the
other two are estimated about 50% too high (still a lot better than
before).  AFAICT there's no easy way to improve those estimates further;
eqjoinsel_semi just plain hasn't got enough information to know how many
matches there will be.

			regards, tom lane

--

-- 
Sent via pgsql-performance mailing list (pgsql-performance <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: Summaries on SSD usage?

On Aug 30, 2011, at 12:23 PM, Stefan Keller wrote:
> I'm looking for summaries (or best practices) on SSD usage with PostgreSQL.
> My use case is mainly a "read-only" database.
> Are there any around?

I'm not sure, but for read-only why not just put more memory in the server? It'll be a lot cheaper than SSDs.
--
Jim C. Nasby, Database Architect                   jim <at> nasby.net
512.569.9461 (cell)                         http://jim.nasby.net

--

-- 
Sent via pgsql-performance mailing list (pgsql-performance <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: 8.4 optimization regression?

On 02/09/11 11:13, Tom Lane wrote:
> I wrote:
>> Mark Kirkwood<mark.kirkwood <at> catalyst.net.nz>  writes:
>>> [ assorted examples showing that commit
>>> 7f3eba30c9d622d1981b1368f2d79ba0999cdff2 has got problems ]
>> ...
>> So, not only are you correct that we should revert the changes to
>> eqjoinsel_inner, but what's happening in eqjoinsel_semi is wrong too.
> I've retested these examples with the patches I committed yesterday.
> Six of the eight examples are estimated pretty nearly dead on, while the
> other two are estimated about 50% too high (still a lot better than
> before).  AFAICT there's no easy way to improve those estimates further;
> eqjoinsel_semi just plain hasn't got enough information to know how many
> matches there will be.
>
>

Just noticed your two commits this morning and ran them through the 
examples too - results look really good! Not only are the plain join 
queries looking way better but that last semi join that was way off is 
now being estimated pretty close. Should be interesting to see how much 
this improves more complex queries!

Cheers

Mark

--

-- 
Sent via pgsql-performance mailing list (pgsql-performance <at> postgresql.org)
To make changes to your subscription:

Re: Summaries on SSD usage?

You mean something like "Unlogged Tables" in PostgreSQL 9.1 (=
in-memory database) or simply a large ramdisk?

Yours, Stefan

2011/9/1 Jim Nasby <jim <at> nasby.net>:
> On Aug 30, 2011, at 12:23 PM, Stefan Keller wrote:
>> I'm looking for summaries (or best practices) on SSD usage with PostgreSQL.
>> My use case is mainly a "read-only" database.
>> Are there any around?
>
> I'm not sure, but for read-only why not just put more memory in the server? It'll be a lot cheaper than SSDs.
> --
> Jim C. Nasby, Database Architect                   jim <at> nasby.net
> 512.569.9461 (cell)                         http://jim.nasby.net
>
>
>

--

-- 
Sent via pgsql-performance mailing list (pgsql-performance <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: 8.4 optimization regression?

On 02/09/11 11:18, Mark Kirkwood wrote:
> On 02/09/11 11:13, Tom Lane wrote:
>> I wrote:
>>> Mark Kirkwood<mark.kirkwood <at> catalyst.net.nz>  writes:
>>>> [ assorted examples showing that commit
>>>> 7f3eba30c9d622d1981b1368f2d79ba0999cdff2 has got problems ]
>>> ...
>>> So, not only are you correct that we should revert the changes to
>>> eqjoinsel_inner, but what's happening in eqjoinsel_semi is wrong too.
>> I've retested these examples with the patches I committed yesterday.
>> Six of the eight examples are estimated pretty nearly dead on, while the
>> other two are estimated about 50% too high (still a lot better than
>> before).  AFAICT there's no easy way to improve those estimates further;
>> eqjoinsel_semi just plain hasn't got enough information to know how many
>> matches there will be.
>>
>>
>
> Just noticed your two commits this morning and ran them through the 
> examples too - results look really good! Not only are the plain join 
> queries looking way better but that last semi join that was way off is 
> now being estimated pretty close. Should be interesting to see how 
> much this improves more complex queries!
>
>

While this is still fresh in your mind, a couple of additional anti join 
queries are still managing to sneak past estimation:

EXPLAIN ANALYZE SELECT 1 FROM nodekeyword nk WHERE nk.keywordid < 100000 

Re: Summaries on SSD usage?

On 2011-09-01 23:28, Jim Nasby wrote:
> On Aug 30, 2011, at 12:23 PM, Stefan Keller wrote:
>> I'm looking for summaries (or best practices) on SSD usage with PostgreSQL.
>> My use case is mainly a "read-only" database.
>> Are there any around?
> I'm not sure, but for read-only why not just put more memory in the server? It'll be a lot cheaper than SSDs
It is "really expensive" to go over 512GB memory and the performance 
regression for
just hitting disk in a system where you assume everything is in memory is
really huge. SSD makes the "edge" be a bit smoother than rotating drives 
do.

Jesper

-- 
Jesper

--

-- 
Sent via pgsql-performance mailing list (pgsql-performance <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: Summaries on SSD usage?

On Tue, Aug 30, 2011 at 11:23 AM, Stefan Keller <sfkeller <at> gmail.com> wrote:
> Hi,
>
> I'm looking for summaries (or best practices) on SSD usage with PostgreSQL.
> My use case is mainly a "read-only" database.
> Are there any around?

How big is your DB?
What kind of reads are most common, random access or sequential?
How big of a dataset do you pull out at once with a query.

SSDs are usually not a big winner for read only databases.
If the dataset is small (dozen or so gigs)  get more RAM to fit it in
If it's big and sequentially accessed, then build a giant RAID-10 or RAID-6
If it's big and randomly accessed then buy a bunch of SSDs and RAID them

--

-- 
Sent via pgsql-performance mailing list (pgsql-performance <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: Re: How to track number of connections and hosts to Postgres cluster