Greg Smith wrote:
Yeah - with 64K chunksize I'm seeing a result more congruent with
yours (866 or so for 24 clients)
That's good to hear. If adjusting that helped so much, you might
consider aligning the filesystem partitions to the chunk size too; the
partition header usually screws that
Stef Telford wrote:
Hello Mark,
For the record, this is a 'base' debian 5 install (with openVZ but
postgreSQL is running on the base hardware, not inside a container)
and I have -explicitly- enabled sync in the conf. Eg;
fsync = on# turns forced
On Wed, Apr 1, 2009 at 4:15 PM, Scott Carey wrote:
>
> On 4/1/09 9:54 AM, "Scott Marlowe" wrote:
>
>> On Wed, Apr 1, 2009 at 10:48 AM, Stef Telford wrote:
>>> Scott Marlowe wrote:
On Wed, Apr 1, 2009 at 10:15 AM, Stef Telford wrote:
> I do agree that the benefit is probably fr
On Wed, 1 Apr 2009, Scott Carey wrote:
On 4/1/09 9:54 AM, "Scott Marlowe" wrote:
On Wed, Apr 1, 2009 at 10:48 AM, Stef Telford wrote:
Scott Marlowe wrote:
On Wed, Apr 1, 2009 at 10:15 AM, Stef Telford wrote:
I do agree that the benefit is probably from write-caching, but I
think tha
On 4/1/09 1:44 PM, "Stef Telford" wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Stef Telford wrote:
>> Stef Telford wrote:
>> Fyi, I got my intel x25-m in the mail, and I have been benching it
>> for the past hour or so. Here are some of the rough and ready
>> figures. Note that
On 4/1/09 9:15 AM, "Stef Telford" wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Greg Smith wrote:
>> On Wed, 1 Apr 2009, Stef Telford wrote:
>>
>>> I have -explicitly- enabled sync in the conf...In fact, if I turn
>>> -off- sync commit, it gets about 200 -slower- rather than
>>
On 4/1/09 9:54 AM, "Scott Marlowe" wrote:
> On Wed, Apr 1, 2009 at 10:48 AM, Stef Telford wrote:
>> Scott Marlowe wrote:
>>> On Wed, Apr 1, 2009 at 10:15 AM, Stef Telford wrote:
>>>
I do agree that the benefit is probably from write-caching, but I
think that this is a 'win' as l
On 4/1/09 10:01 AM, "Matthew Wakeling" wrote:
> On Wed, 1 Apr 2009, Stef Telford wrote:
>>Good UPS, a warm PITR standby, offsite backups and regular checks is
>> "good enough" for me, and really, that's what it all comes down to.
>> Mitigating risk and factors into an 'acceptable' amount for
> Can I try again? :)
>
> How hard would it be to teach the planner about preserving uniqueness of
> relations in subqueries?
> And using that information to remove unnecessary self joins on unique sets?
>
> I can try to rewrite some queries to test it on real data for how much
> gain it would prov
On Wed, 1 Apr 2009, da...@lang.hm wrote:
On Wed, 1 Apr 2009, Mark Kirkwood wrote:
Scott Carey wrote:
A little extra info here >> md, LVM, and some other tools do not allow
the
file system to use write barriers properly So those are on the bad
list
for data integrity with SAS or SATA
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stef Telford wrote:
> Stef Telford wrote:
>> Mark Kirkwood wrote:
>>> Scott Carey wrote:
A little extra info here >> md, LVM, and some other tools do
not allow the file system to use write barriers properly
So those are on the bad
On Wed, 1 Apr 2009, Mark Kirkwood wrote:
Scott Carey wrote:
A little extra info here >> md, LVM, and some other tools do not allow the
file system to use write barriers properly So those are on the bad list
for data integrity with SAS or SATA write caches without battery back-up.
However,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stef Telford wrote:
> Mark Kirkwood wrote:
>> Scott Carey wrote:
>>> A little extra info here >> md, LVM, and some other tools do
>>> not allow the file system to use write barriers properly So
>>> those are on the bad list for data integrity wit
Tom Lane wrote:
> Rikard Pavelic writes:
>
>> It would be great if Postgres could rewrite this query
>>
>
> AFAICS those queries are not going to produce the same results,
> so Postgres would be 100% incorrect to rewrite it like that for you.
>
> (If they do produce the same results, it wo
On Wed, 1 Apr 2009, Matthew Wakeling wrote:
So, I have written a plpgsql function to calculate overlaps. It works
reasonably quickly where there aren't that many overlaps. However, it seems
to go very slowly when there are a large number of rows to return.
In plpgsql, what happens about memory
On Wed, Apr 1, 2009 at 11:54 AM, Matthew Wakeling wrote:
> On Wed, 1 Apr 2009, Greg Smith wrote:
>>
>> The only real way to know if a UPS is working right is to actually detach
>> power and confirm the battery still works, which is downtime nobody ever
>> feels is warranted for a production system
On Wed, 1 Apr 2009, Greg Smith wrote:
The only real way to know if a UPS is working right is to actually detach
power and confirm the battery still works, which is downtime nobody ever
feels is warranted for a production system. Then, one day the power dies,
the UPS battery doesn't work to spe
On Wed, 1 Apr 2009, Scott Marlowe wrote:
Meteor strike is far less likely than a power surge taking out a UPS.
I average having a system go down during a power outage because the UPS it
was attached to wasn't working right anymore about once every five years.
And I don't usually manage that
On Mon, 30 Mar 2009, Віталій Тимчишин wrote:
What is the bad plan? Is it like the first plan from your first message?
It's the plan a few messages back. The UNION ALL query I showed
effectively got the database to do it both ways round.
It's the case that a "between" index scan will return m
Rikard Pavelic writes:
> It would be great if Postgres could rewrite this query
AFAICS those queries are not going to produce the same results,
so Postgres would be 100% incorrect to rewrite it like that for you.
(If they do produce the same results, it would depend on a bunch
of assumptions you
Matthew Wakeling wrote:
> On Wed, 1 Apr 2009, Stef Telford wrote:
>>Good UPS, a warm PITR standby, offsite backups and regular checks is
>> "good enough" for me, and really, that's what it all comes down to.
>> Mitigating risk and factors into an 'acceptable' amount for each person.
>> However,
On Wed, 1 Apr 2009, Віталій Тимчишин wrote:
The outer nested join has the VALUES as the main loop, and the
complicated join as the leaf. So, the complicated
overlap-finding join gets run twice.
That's weird. What do you have as statistics target? Planner is incorrect few
orders of
On Wed, Apr 1, 2009 at 11:01 AM, Matthew Wakeling wrote:
> On Wed, 1 Apr 2009, Stef Telford wrote:
>>
>> Good UPS, a warm PITR standby, offsite backups and regular checks is
>> "good enough" for me, and really, that's what it all comes down to.
>> Mitigating risk and factors into an 'acceptable'
On Wed, 1 Apr 2009, Stef Telford wrote:
Good UPS, a warm PITR standby, offsite backups and regular checks is
"good enough" for me, and really, that's what it all comes down to.
Mitigating risk and factors into an 'acceptable' amount for each person.
However, if you see over a 2x improvement fr
On Wed, Apr 1, 2009 at 10:48 AM, Stef Telford wrote:
> Scott Marlowe wrote:
>> On Wed, Apr 1, 2009 at 10:15 AM, Stef Telford wrote:
>>
>>> I do agree that the benefit is probably from write-caching, but I
>>> think that this is a 'win' as long as you have a UPS or BBU adaptor,
>>> and really,
On Wed, 1 Apr 2009, Scott Marlowe wrote:
On Wed, Apr 1, 2009 at 10:15 AM, Stef Telford wrote:
I do agree that the benefit is probably from write-caching, but I
think that this is a 'win' as long as you have a UPS or BBU adaptor,
and really, in a prod environment, not having a UPS is .. well
Scott Marlowe wrote:
> On Wed, Apr 1, 2009 at 10:15 AM, Stef Telford wrote:
>
>> I do agree that the benefit is probably from write-caching, but I
>> think that this is a 'win' as long as you have a UPS or BBU adaptor,
>> and really, in a prod environment, not having a UPS is .. well. Crazy
On Wed, 1 Apr 2009, Rikard Pavelic wrote:
It would be great if Postgres could rewrite this query
SELECT bt1.id, bt1.total, sq.id, sq.total
FROM
big_table bt1
INNER JOIN small_table st1 on st1.big_id = bt1.id
INNER JOIN
(
SELECT bt2.id, st2.total
On Wed, Apr 1, 2009 at 10:15 AM, Stef Telford wrote:
> I do agree that the benefit is probably from write-caching, but I
> think that this is a 'win' as long as you have a UPS or BBU adaptor,
> and really, in a prod environment, not having a UPS is .. well. Crazy ?
You do know that UPSes can
How hard would it be to teach planer to optimize self join?
While this query which demonstrates it is not that common
SELECT count(*)
FROM
big_table a
INNER JOIN big_table b ON a.id = b.id;
This type of query (self joining large table) is very common
(at least in our environment
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Greg Smith wrote:
> On Wed, 1 Apr 2009, Stef Telford wrote:
>
>> I have -explicitly- enabled sync in the conf...In fact, if I turn
>> -off- sync commit, it gets about 200 -slower- rather than
>> faster.
>
> You should take a look at
> http://www.postg
On Wed, 1 Apr 2009, Stef Telford wrote:
I have -explicitly- enabled sync in the conf...In fact, if I turn -off-
sync commit, it gets about 200 -slower- rather than faster.
You should take a look at
http://www.postgresql.org/docs/8.3/static/wal-reliability.html
And check the output from "hdp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark Kirkwood wrote:
> Scott Carey wrote:
>>
>> A little extra info here >> md, LVM, and some other tools do not
>> allow the file system to use write barriers properly So
>> those are on the bad list for data integrity with SAS or SATA
>> write
On Wed, Apr 1, 2009 at 5:10 AM, Mahu Vasile wrote:
> tcp_keepalives_count = 1 # TCP_KEEPCNT;
This might not be what you want.
http://www.postgresql.org/docs/8.3/static/runtime-config-connection.html
Presumably you'd like to wait more than 1 second before declaring the
connection
henk de wit writes:
> I still have some work to do to find out why dumping in the custom
> format is so much slower.
Offhand the only reason I can see for it to be much different from
plain-text output is that -Fc compresses by default. If you don't
care about that, try -Fc -Z0.
Hi,
> henk de wit writes:
>> For performance reasons (obviously ;)) I'm experimenting with parallel
>> restore in PG 8.4. [...] I got this message however:
>> [...]
>> pg_restore: [archiver] WARNING: archive is compressed, but this
>> installation does not support compression -- no data will be
Hi
I have some problems with the PostgreSQL 8.3.6.
The client(Microsoft Access 2000) link postgresql table(via ODBC) and
work with this. Sometimes on the client appear:
ODBC--call failed.
Could not send Query(connection dead)(#26);
In PostgreSQL log appear:
could not receive dat
Scott Carey wrote:
On 3/25/09 9:28 PM, "Mark Kirkwood" wrote:
Rebuilt with 64K chunksize:
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 24
number of transactions per client: 12000
number of transactions actually processed: 288000/288000
tps = 866.512162 (includi
Scott Carey wrote:
A little extra info here >> md, LVM, and some other tools do not allow the
file system to use write barriers properly So those are on the bad list
for data integrity with SAS or SATA write caches without battery back-up.
However, this is NOT an issue on the postgres data
39 matches
Mail list logo
