On 11/05/2010, Sergey Konoplev wrote:
> On 11 May 2010 10:18, venu madhav wrote:
>> select e.cid, timestamp, s.sig_class, s.sig_priority, s.sig_name,
>> e.sniff_ip, e.sniff_channel, s.sig_config, e.wifi_addr_1,
>> e.wifi_addr_2, e.view_status, bssid FROM event e, signature s WHERE
>> s.sig_id =
In response to venu madhav :
> Hi all,
>In my database application, I've a table whose records can
> reach 10M and insertions can happen at a faster rate like 100
> insertions per second in the peak times. I configured postgres to do
> auto vacuum on hourly basis. I have frontend GUI applic
On 11 May 2010 10:18, venu madhav wrote:
> select e.cid, timestamp, s.sig_class, s.sig_priority, s.sig_name,
> e.sniff_ip, e.sniff_channel, s.sig_config, e.wifi_addr_1,
> e.wifi_addr_2, e.view_status, bssid FROM event e, signature s WHERE
> s.sig_id = e.signature AND e.timestamp >= '1270449180'
Hi all,
In my database application, I've a table whose records can
reach 10M and insertions can happen at a faster rate like 100
insertions per second in the peak times. I configured postgres to do
auto vacuum on hourly basis. I have frontend GUI application in CGI
which displays the data fr
Thanks for all the help. Performance is back where I thought it
should be, after I fixed our pooling bug.
I didn't think that postgres would be released with performance issues
like that - its just too good :)
Thanks,
Dan
---(end of broadcast)---
On Thu, Feb 14, 2008 at 7:56 PM, Dan Armbrust
<[EMAIL PROTECTED]> wrote:
> On Thu, Feb 14, 2008 at 1:31 PM, Dave Page <[EMAIL PROTECTED]> wrote:
>
> > You must have enabled the debugger when you installed (or didn't
> > disable it). You can turn it back off in postgresql.conf if you like -
> >
Dan Armbrust wrote:
Are there any known regression issues WRT performance on the 8.3.0.1
binary build for windows?
And I mean serious -multiple orders of magnitude- performance issues
running simple queries on a small database...
A little more background. I built 8.3.0 on Cent OS 5 today. Sta
So, my ill Postgres 8.3 database is filling up log files in the pg_log
directory with the following:
2008-02-13 18:29:31 CST LOG: loaded library
"$libdir/plugins/plugin_debugger.dll"
2008-02-13 18:29:31 CST LOG: loaded library
"$libdir/plugins/plugin_debugger.dll"
2008-02-13 18:29:31 CST LOG: l
Are there any known regression issues WRT performance on the 8.3.0.1
binary build for windows?
And I mean serious -multiple orders of magnitude- performance issues
running simple queries on a small database...
A little more background. I built 8.3.0 on Cent OS 5 today. Started
using it with a s
On 23/09/2007, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>
> Christian Schröder wrote:
> > Alvaro Herrera wrote:
> >> Christian Schröder wrote:
> >>
> >>
> >>> I think it is my job as db admin to make the database work the way my
> >>> users need it, and not the user's job to find a solution that f
Christian Schröder wrote:
> Alvaro Herrera wrote:
>> Christian Schröder wrote:
>>
>>
>>> I think it is my job as db admin to make the database work the way my
>>> users need it, and not the user's job to find a solution that fits the
>>> database's needs ...
>>>
>>> Is there really nothing tha
Alvaro Herrera wrote:
Christian Schröder wrote:
I think it is my job as db admin to make the database work the way my users
need it, and not the user's job to find a solution that fits the database's
needs ...
Is there really nothing that I can do?
You can improve the selectivity e
Christian Schröder wrote:
> I think it is my job as db admin to make the database work the way my users
> need it, and not the user's job to find a solution that fits the database's
> needs ...
>
> Is there really nothing that I can do?
You can improve the selectivity estimator function. One i
John D. Burger wrote:
Christian Schröder wrote:
Or would it be possible to tweak how the planner determines the
selectivity? I have read in the docs (chapter 54.1) that in case of
more than one condition in the where clause, independency is assumed.
In my case ("... where test like '11%' and
Christian Schröder wrote:
Or would it be possible to tweak how the planner determines the
selectivity? I have read in the docs (chapter 54.1) that in case of
more than one condition in the where clause, independency is
assumed. In my case ("... where test like '11%' and test not like
'113
Hi list,
I am still fighting with the really slow database queries (see
http://www.nabble.com/%22like%22-vs-%22substring%22-again-t4447906.html),
and I still believe that the cause of the problem is that the query
planner makes incorrect estimations about the selectivity of the "where"
clauses
On 16-May-07, at 4:05 PM, PFC wrote:
This makes queries hard to optimize. Consider the table (user_id,
item_id) meaning user selected this item as favourite.
If you want to know which users did select both items 1 and 2, you
have to do a self-join, something like :
SELECT... FROM favourite
We use bitfields on our large user table. It is becoming unworkable to
scan for matches, since overall most people have very few selections
made.
We are moving it to a model like your favorite_colors table which just
links the option and the user.
We find that doing joins on large tables
On May 15, 2007, at 10:35 AM, Bill Moseley wrote:
For some value of "large", is there a time when one might consider
using a single column in the user or user_prefs table to represent
their color choices instead of a link table?
We use bitfields on our large user table. It is becoming unwork
On May 14, 2007, at 4:37 PM, Bill Moseley wrote:
Say that there's also about 10 columns of settings or preferences for
each user. Are there any cases or reasons to have a separate
"user_preferences" table vs. just placing all the columns together in
one table?
when you have, say 65 million u
On Tue, May 15, 2007 at 09:20:53PM +0200, PFC wrote:
> >From an outside perspective it just
> >seems odd that potentially a large amount of data would be pulled off
> >disk into memory that is never used. Perhaps there's an overriding
> >reason for this.
>
> Yeah, where would you put this d
Thus, if there are a whole bunch of columns on each table, the data in
those extra columns (e.g. - all columns aside from "id", the one that
was asked for in the result set) will indeed be drawn into memory.
Yeah, I wanted to mean that ;)
All the columns are loaded (except the TOASTed
On May 15, 2007, at 12:02 PM, Bill Moseley wrote:
On Tue, May 15, 2007 at 01:42:18PM -0400, Chris Browne wrote:
[EMAIL PROTECTED] (PFC) writes:
SELECT o.id
FROM order o
JOIN customer c on o.customer = c.id
Does that bring into memory all columns from both order and
customer?
M
Thus, if there are a whole bunch of columns on each table, the
data in
those extra columns (e.g. - all columns aside from "id", the one that
was asked for in the result set) will indeed be drawn into memory.
Is that specific to Postgresql? From an outside perspective it just
seems odd that po
On Tue, May 15, 2007 at 01:42:18PM -0400, Chris Browne wrote:
> [EMAIL PROTECTED] (PFC) writes:
> >> SELECT o.id
> >> FROM order o
> >> JOIN customer c on o.customer = c.id
> >>
> >> Does that bring into memory all columns from both order and customer?
> >> Maybe that's not a good examp
One other possible reason for splitting the table up in two chunks is to
grant different rights on the 2 sets of columns.
Susan Cassidy
Bill Moseley <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
05/15/2007 09:44 AM
To
Postgres General
cc
Subject
Re: [GENERAL] Performance issues
[EMAIL PROTECTED] (PFC) writes:
>> SELECT o.id
>> FROM order o
>> JOIN customer c on o.customer = c.id
>>
>> Does that bring into memory all columns from both order and customer?
>> Maybe that's not a good example due to indexes.
>
> No, it just pulls the columns you ask from the
SELECT o.id
FROM order o
JOIN customer c on o.customer = c.id
Does that bring into memory all columns from both order and customer?
Maybe that's not a good example due to indexes.
No, it just pulls the columns you ask from the table, nothing less,
nothing more.
Splitting tab
On Tue, May 15, 2007 at 07:51:44AM +0200, Dawid Kuroczko wrote:
> On 5/15/07, Bill Moseley <[EMAIL PROTECTED]> wrote:
> >On Tue, May 15, 2007 at 06:33:26AM +0200, Dawid Kuroczko wrote:
> >> Well, views are not going to help with memory consumption here.
> >> It is the table contents that gets cache
I'm sure there's a point where you'd be saving a "substantial" amount
of disk space using a non-normalized scheme, but, like you say, you'd
be missing out on other things. In general, disks are cheap while the
man hours used to try to fix data corruption is not.
On May 15, 2007, at 7:35 AM,
Can anyone provide input on this question? I'm curious how to look at
this from a disk and memory usage perspective. Would using a bit
column type help much?
I'm not thrilled by the loss of referential integrity.
On Mon, May 14, 2007 at 01:37:18PM -0700, Bill Moseley wrote:
>
> Say I have a ta
Say, if you first SELECT fname, lname FROM user_table;
and then you issue SELECT * FROM user_table; -- the
second select will be returned from buffer cache -- since
all rows are already in the cache.
...Unless your table contains some large TEXT columns that have been
stored out of line (T
On 5/15/07, Bill Moseley <[EMAIL PROTECTED]> wrote:
On Tue, May 15, 2007 at 06:33:26AM +0200, Dawid Kuroczko wrote:
> Well, views are not going to help with memory consumption here.
> It is the table contents that gets cached in buffer cache, not the
> views contents. So if you have a view which
On Tue, May 15, 2007 at 06:33:26AM +0200, Dawid Kuroczko wrote:
> Well, views are not going to help with memory consumption here.
> It is the table contents that gets cached in buffer cache, not the
> views contents. So if you have a view which returns only one
> column from 15-column table, you w
On 5/14/07, Rich Shepard <[EMAIL PROTECTED]> wrote:
On Mon, 14 May 2007, PFC wrote:
> I did something like that on MySQL some time ago.
> In the Users table there was stuff that other users need to see (like
> his login name, etc), and stuff that only this user needs to see (like his
On Mon, 14 May 2007, PFC wrote:
I did something like that on MySQL some time ago.
In the Users table there was stuff that other users need to see (like
his login name, etc), and stuff that only this user needs to see (like his
preferences).
So, when displaying posts in the forum, for
On Mon, May 14, 2007 at 10:52:13PM +0200, PFC wrote:
>
> >Say I have a "user" table that has first, last, email, password, and
> >last_accessed columns. This user table will be accessed often. (It's
> >not really "user", but that's not important in this discussion)
> >
> >Say that there's also a
Say I have a "user" table that has first, last, email, password, and
last_accessed columns. This user table will be accessed often. (It's
not really "user", but that's not important in this discussion)
Say that there's also about 10 columns of settings or preferences for
each user. Are there
Is there any benefit of splitting up a table into two tables that will
always have a one-to-one relationship?
Say I have a "user" table that has first, last, email, password, and
last_accessed columns. This user table will be accessed often. (It's
not really "user", but that's not important in
Diagnosing JBossCMP issues is not for the faint of heart, in that one
of its main raison d'etre's is to hide SQL knowledge away from the
casual coder. Add into the mix the concurrency issues which naturally
occur since an EJB container is multithreaded and the overly
complicated JTA stuff a
Andy Dale wrote:
Hi,
I will explain in more details what the test (extremely simple) program is
actually doing. A session bean receives some data (roughly 3K) and then
persists this data to the database with EntityManager.persist() (using the
EJB 3.0 Persistence API that comes with JBoss). Onc
Andy Dale wrote:
Hi,
I have performed some tests earlier on today, and i think the problem lies
with Postgres and it's bad performance when being used with container
managed persistence.
Is your problem performance or an error? It sounded like you were
getting errors in your first post.
>
Hi,I have performed some tests earlier on today, and i think
the problem lies with Postgres and it's bad performance when being used
with container managed persistence. I am covinced of it being an issue
with postgres because it works really well with MySQL and Hypersonic,
but not with Postgres.
"Andy Dale" <[EMAIL PROTECTED]> writes:
> The current problem we seem to have is that the data is persisted ok
> (or at least it seems to be in there with pgadmin), but cannot be
> read back out of the database all the time (in fact for about 90% of
> the time), the current behaviour of the applic
Hi,We currently have an JBoss web application that persists a byte array it recieves (Using the EJB persistence API), and then tries to read it from the Database again from further parsing. The application works really well with the default Hypersonic datasource, but it will not work correctly whe
45 matches
Mail list logo
