would it cause problem in postgres DB if /var/lib/psql partition is mounted
with "noatime"?
TIA
JM
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so
On Tue, Sep 09, 2003 at 04:12:48PM +0800, JM wrote:
> would it cause problem in postgres DB if /var/lib/psql partition is mounted
> with "noatime"?
No; in fact, that's been suggested by many people. I don't know
whether anyone's done any tests to prove that it helps.
A
--
Andrew Sullivan
Hello,
I have small table (up to 1 rows) and every row will be updated
once per minute. Table also has "before update on each row" trigger
written in plpgsql. But trigger 99.99% of the time will do nothing
to the database. It will just compare old and new values in the row
and those value
Andrew Sullivan wrote:
On Tue, Sep 09, 2003 at 04:12:48PM +0800, JM wrote:
would it cause problem in postgres DB if /var/lib/psql partition is mounted
with "noatime"?
No; in fact, that's been suggested by many people. I don't know
whether anyone's done any tests to prove that it helps.
http://
On Tuesday 09 September 2003 13:40, Mindaugas Riauba wrote:
> Hello,
>
> I have small table (up to 1 rows) and every row will be updated
> once per minute. Table also has "before update on each row" trigger
> written in plpgsql. But trigger 99.99% of the time will do nothing
> to the databa
> How can I improve performance and will version 7.4 bring something
> valuable for my task? Rewrite to some other scripting language is not
> a problem. Trigger is simple enough.
Your best bet is to have additional clients connected to the database
requesting work. Approx NUMCPUs * 2 + 1 seems
> > How can I improve performance and will version 7.4 bring something
> > valuable for my task? Rewrite to some other scripting language is not
> > a problem. Trigger is simple enough.
>
> Well, try it without the trigger. If performance improves markedly, it
might
> be worth rewriting in C.
I did not expect so many answers about this question.
Thanks.
I find by myself the "order by trick" to speed min/max function.
Jean-Gérard Pailloncy
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
s
On Tue, 9 Sep 2003, Mindaugas Riauba wrote:
>
> Hello,
>
> I have small table (up to 1 rows) and every row will be updated
> once per minute. Table also has "before update on each row" trigger
> written in plpgsql. But trigger 99.99% of the time will do nothing
> to the database. It will
On Tuesday 09 September 2003 14:33, Mindaugas Riauba wrote:
> > Well, try it without the trigger. If performance improves markedly, it
> might
> > be worth rewriting in C.
>
> Nope. Execution time is practically the same without trigger.
OK - no point in rewriting it then.
> > If not, you're pr
"Mindaugas Riauba" <[EMAIL PROTECTED]> writes:
>> Well, try it without the trigger. If performance improves markedly, it
>> might be worth rewriting in C.
> Nope. Execution time is practically the same without trigger.
>> If not, you're probably saturating the disk I/O -
> Bottleneck in this
Mindaugas Riauba kirjutas T, 09.09.2003 kell 15:40:
> Hello,
>
> I have small table (up to 1 rows) and every row will be updated
> once per minute. Table also has "before update on each row" trigger
> written in plpgsql. But trigger 99.99% of the time will do nothing
> to the database. It
> "AS" == Andrew Sullivan <[EMAIL PROTECTED]> writes:
AS> On Tue, Sep 09, 2003 at 04:12:48PM +0800, JM wrote:
>> would it cause problem in postgres DB if /var/lib/psql partition is mounted
>> with "noatime"?
AS> No; in fact, that's been suggested by many people. I don't know
AS> whether any
The only connection to MVCC is that the "obvious" solution doesn't work,
namely storing a cache of the aggregate in the table information.
So what would it take to implement this for "all" aggregates? Where I think
"all" really just means min(), max(), first(), last().
I think it would mean hav
Greg,
> The only connection to MVCC is that the "obvious" solution doesn't work,
> namely storing a cache of the aggregate in the table information.
Well, that solution also doesn't work if you use a WHERE condition or JOIN,
now does it?
> So what would it take to implement this for "all" aggre
On Tue, Sep 09, 2003 at 12:54:04 -0400,
Greg Stark <[EMAIL PROTECTED]> wrote:
>
> So what would it take to implement this for "all" aggregates? Where I think
> "all" really just means min(), max(), first(), last().
There can be other aggregates where indexes are helpful. The case of interest
is
Tom Lane wrote:
>"scott.marlowe" <[EMAIL PROTECTED]> writes:
>
>
>>On Mon, 8 Sep 2003, Neil Conway wrote:
>>
>>
>>>As was pointed out in a thread a couple days ago, MIN/MAX() optimization
>>>has absolutely nothing to do with MVCC. It does, however, make
>>>optimizing COUNT() more difficult.
On Tue, Sep 09, 2003 at 14:06:56 -0500,
Thomas Swan <[EMAIL PROTECTED]> wrote:
>
> Would it be possible to rewrite min and max at the parser level into a
> select/subselect (clause) condition ( repeat condition ) order by
> (clause ) descending/ascending limit 1 and thereby avoiding the
> penal
I've got an application that needs to chunk through ~2GB of data. The
data is ~7000 different sets of 300 records each. I put all of the data
into a postgres database but that doesn't look like its going to work
because of how the data lives on the disk.
When the app runs on a 500 Mhz G4 the CP
Chris,
> I've got an application that needs to chunk through ~2GB of data. The
> data is ~7000 different sets of 300 records each. I put all of the data
> into a postgres database but that doesn't look like its going to work
> because of how the data lives on the disk.
Your problem is curable
> > Know what we (OK, I) need? An explicitly non-aggregate max() and min(),
> > implemented differently, so they can be optimised.
>
> Not per se. The way I've been visualizing this is that we add to
> pg_aggregate a column named, say, aggsortop, with the definition:
...snip of cunning potentiall
Matt Clark wrote:
> > Just a data point, but on my Dual Xeon 2.4Gig machine with a 10k SCSI
> > drive I can do 4k inserts/second if I turn fsync off. If you have a
> > battery-backed controller, you should be able to do the same. (You will
> > not need to turn fsync off --- fsync will just be fas
22 matches
Mail list logo
