On 15.10.2012 17:01, Craig James wrote:
On Thu, Oct 11, 2012 at 11:14 AM, Andrea Suisani
wrote:
> I've googled a bit and I've found a way to disable hyperthreading
> without
> the need to reboot the system and entering the bios:
>
> echo 0 >/sys/devices/system/node/no
On 10/16/2012 04:59 AM, houmanb wrote:
There is an Index on T.c. But would it help to partition the table by T.c?
You should really post EXPLAIN ANALYZE for questions like this. See
https://wiki.postgresql.org/wiki/Slow_Query_Questions
--
Craig Ringer
--
Sent via pgsql-performance mailin
On Mon, Oct 15, 2012 at 1:59 PM, houmanb wrote:
> Dear all,
> We have a DB containing transactional data.
> There are about *50* to *100 x 10^6* rows in one *huge* table.
> We are using postgres 9.1.6 on linux with a *SSD card on PCIex* providing us
> a constant seeking time.
>
> A typical select
Houman,
Partition by date and revise your processes to create and load a new child
table every day. Since you already know the date append it to the table base
name and go straight to the data you need. Also, the index on T.c won't help
for this query, you're looking at a full table scan eve
Hi,
On 16 October 2012 07:59, houmanb wrote:
> Dear all,
> We have a DB containing transactional data.
> There are about *50* to *100 x 10^6* rows in one *huge* table.
> We are using postgres 9.1.6 on linux with a *SSD card on PCIex* providing us
> a constant seeking time.
How many columns? What
On Mon, Oct 15, 2012 at 5:59 PM, houmanb wrote:
> Dear all,
> We have a DB containing transactional data.
> There are about *50* to *100 x 10^6* rows in one *huge* table.
> We are using postgres 9.1.6 on linux with a *SSD card on PCIex* providing
> us
> a constant seeking time.
>
> A typical sele
On Mon, Oct 15, 2012 at 3:59 PM, houmanb wrote:
> Dear all,
> We have a DB containing transactional data.
> There are about *50* to *100 x 10^6* rows in one *huge* table.
> We are using postgres 9.1.6 on linux with a *SSD card on PCIex* providing us
> a constant seeking time.
>
> A typical select
Dear all,
We have a DB containing transactional data.
There are about *50* to *100 x 10^6* rows in one *huge* table.
We are using postgres 9.1.6 on linux with a *SSD card on PCIex* providing us
a constant seeking time.
A typical select (see below) takes about 200 secs. As the database is the
back
Hi,
> henk de wit writes:
> > For some reason the mailinglist software seems to block the email as soon
> > as the planner details are in it, so I pasted those on pastebin.com:
> > http://pastebin.com/T5JTwh5T
>
> You need a less horrid estimate for the join size. Possibly an ANALYZE
> on th
On 10/15/2012 05:34 PM, Scott Marlowe wrote:
On Mon, Oct 15, 2012 at 9:28 AM, Claudio Freire wrote:
On Mon, Oct 15, 2012 at 12:24 PM, Andrea Suisani wrote:
sure you're right.
It's just that my bet was on a higher throughput
when HT was isabled from the BIOS (as you stated
previously in this
On 10/15/2012 05:28 PM, Claudio Freire wrote:
On Mon, Oct 15, 2012 at 12:24 PM, Andrea Suisani wrote:
It does prove they're not equivalent though.
sure you're right.
It's just that my bet was on a higher throughput
when HT was isabled from the BIOS (as you stated
previously in this thread).
[cut]
TPS including connection establishing, pgbench run in a single
thread mode, connection made through unix socket, OS cache dropped
and Postgres restarted for every run.
those are the results:
HTHT SYSFS DISHT BIOS DISABLE
-c -t r1 r2 r3r1 r2 r3
On Mon, Oct 15, 2012 at 9:28 AM, Claudio Freire wrote:
> On Mon, Oct 15, 2012 at 12:24 PM, Andrea Suisani wrote:
>> sure you're right.
>>
>> It's just that my bet was on a higher throughput
>> when HT was isabled from the BIOS (as you stated
>> previously in this thread).
>
> Yes, mine too. It's
On Mon, Oct 15, 2012 at 9:01 AM, Craig James wrote:
> On Mon, Oct 15, 2012 at 1:27 AM, Andrea Suisani wrote:
>> (I suspect that there's something wrong with the PERC
>> because, having the controller cache enabled make no
>> difference in terms of TPS), it seems strange that disabling
>> HT from
On Mon, Oct 15, 2012 at 12:24 PM, Andrea Suisani wrote:
>> It does prove they're not equivalent though.
>>
>
> sure you're right.
>
> It's just that my bet was on a higher throughput
> when HT was isabled from the BIOS (as you stated
> previously in this thread).
Yes, mine too. It's bizarre. If I
On 10/15/2012 05:01 PM, Claudio Freire wrote:
On Mon, Oct 15, 2012 at 5:27 AM, Andrea Suisani wrote:
it seems strange that disabling
HT from the bios will give lesser TPS that HT disable through
sysfs interface.
It does prove they're not equivalent though.
sure you're right.
It's just tha
On Mon, Oct 15, 2012 at 5:27 AM, Andrea Suisani wrote:
> it seems strange that disabling
> HT from the bios will give lesser TPS that HT disable through
> sysfs interface.
It does prove they're not equivalent though.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
On Mon, Oct 15, 2012 at 1:27 AM, Andrea Suisani wrote:
> On 10/11/2012 04:40 PM, Andrea Suisani wrote:
>>
>> On 10/11/2012 04:19 PM, Claudio Freire wrote:
>>>
>>> On Thu, Oct 11, 2012 at 11:14 AM, Andrea Suisani
>>> wrote:
sorry to come late to the party, but being in a similar conditio
Hi Henk,
On Sun, Oct 14, 2012 at 9:04 AM, henk de wit wrote:
> Hi,
>
> For some reason the mailinglist software seems to block the email as soon as
> the planner details are in it, so I pasted those on pastebin.com:
> http://pastebin.com/T5JTwh5T
Just an additional data point: for whatever reaso
On Fri, Oct 12, 2012 at 10:31 PM, Tom Lane wrote:
> So I think the original assumption that we didn't need to optimize
> pg_dump's object management infrastructure for blobs still holds good.
> If there's anything that is worth fixing here, it's the number of server
> roundtrips being used ...
>
On 10/11/2012 04:40 PM, Andrea Suisani wrote:
On 10/11/2012 04:19 PM, Claudio Freire wrote:
On Thu, Oct 11, 2012 at 11:14 AM, Andrea Suisani wrote:
sorry to come late to the party, but being in a similar condition
I've googled a bit and I've found a way to disable hyperthreading without
the ne
21 matches
Mail list logo
