Thank you for the detailed explanation.
Regards,
Jayadevan
DISCLAIMER:
"The information in this e-mail and any attachment is intended only for
the person to whom it is addressed and may contain confidential and/or
privileged material. If you have received this e-mail in error, kindly
cont
Jayadevan M wrote:
It is mentioned that table data blocks have data about tuple visibility and hence table scans
are always necessary. So how does PostgreSQL reduce the number of blocks
to be read by using indexes?
To be useful, a query utilizing an index must be selective: it must
only retu
Hello,
> PostgreSQL can't currently avoid reading the table, because that's
> where the tuple visibility information is stored. We've been making
> progress toward having some way to avoid reading the table for all
> except very recently written tuples, but we're not there yet (in any
> production
Appears to have helped with the combination index. I'll need to
eliminate caching effects before making sure its the right choice.
Thanks for the suggestion.
On Tue, Jun 22, 2010 at 7:01 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Anj Adu's message of mar jun 22 17:44:39 -0400
Alvaro Herrera writes:
> Excerpts from Anj Adu's message of mar jun 22 17:44:39 -0400 2010:
>> This query seems unreasonable slow on a well-indexed table (13 million
>> rows). Separate indexes are present on guardid_id , from_num and
>> targetprt columns.
> Maybe you need to vacuum or reindex?
R
I did post the explain analyze..can you please clarify
On Tue, Jun 22, 2010 at 6:10 PM, Joshua D. Drake wrote:
> On Tue, 2010-06-22 at 18:00 -0700, Anj Adu wrote:
>> i have several partitions like this (similar size ...similar data
>> distribution)..these partitions are only "inserted"..never upd
On Tue, 2010-06-22 at 18:00 -0700, Anj Adu wrote:
> i have several partitions like this (similar size ...similar data
> distribution)..these partitions are only "inserted"..never updated.
> Why would I need to vacuum..
>
An explain analyze is what is in order for further diagnosis.
JD
> I can
i have several partitions like this (similar size ...similar data
distribution)..these partitions are only "inserted"..never updated.
Why would I need to vacuum..
I can reindex..just curious what can cause the index to go out of whack.
On Tue, Jun 22, 2010 at 4:44 PM, Alvaro Herrera
wrote:
> Exc
Excerpts from Anj Adu's message of mar jun 22 17:44:39 -0400 2010:
> This query seems unreasonable slow on a well-indexed table (13 million
> rows). Separate indexes are present on guardid_id , from_num and
> targetprt columns.
Maybe you need to vacuum or reindex?
--
Álvaro Herrera
The PostgreS
This query seems unreasonable slow on a well-indexed table (13 million
rows). Separate indexes are present on guardid_id , from_num and
targetprt columns.
The table was analyzed with a default stats target of 600.
Postgres 8.1.9 on 2 cpu quad core 5430 with 32G RAM (work_mem=502400)
6 x 450G 15K
v. 8.4.3
I have a table that has several indexes, one of which the table is clustered
on. If I do an ALTER TABLE Foo ADD COLUMN bar integer not null default -1;
It re-writes the whole table.
* Does it adhere to the CLUSTER property of the table and write the new version
clustered?
* Does it
On Jun 22, 2010, at 7:29 AM, Karl Denninger wrote:
> Justin Graf wrote:
>>
>> On 6/22/2010 4:31 AM, Grzegorz Jaśkiewicz wrote:
>>
>>> Would moving WAL dir to separate disk help potentially ?
>>>
>>>
>>
>> Yes it can have a big impact.
> WAL on a separate spindle will make a HUGE dif
Of course, no backup strategy is complete without testing a full restore
onto bare hardware :-)
On Tue, Jun 22, 2010 at 9:29 AM, Karl Denninger wrote:
> Justin Graf wrote:
>
> On 6/22/2010 4:31 AM, Grzegorz Jaśkiewicz wrote:
>
>
> Would moving WAL dir to separate disk help potentially ?
>
>
>
Justin Graf wrote:
> On 6/22/2010 4:31 AM, Grzegorz Jaśkiewicz wrote:
>
>> Would moving WAL dir to separate disk help potentially ?
>>
>>
>
> Yes it can have a big impact.
WAL on a separate spindle will make a HUGE difference in performance.
TPS rates frequently double OR BETTER with W
Grzegorz Jaśkiewicz wrote:
raid: serveRAID M5014 SAS/SATA controller
Do the "performant servers" have a different RAID card? This one has
terrible performance, and could alone be the source of your issue. The
ServeRAID cards are slow in general, and certainly slow running RAID10.
--
Gr
On 6/22/2010 4:31 AM, Grzegorz Jaśkiewicz wrote:
> Hi folks,
>
> is there a general problem with raid10 performance postgresql on it?
> We see very low performance on writes (2-3x slower than on less
> performant servers). I wonder if it is solely problem of raid10
> configuration, or if it is post
On 22/06/10 00:42, Sergio Charpinel Jr. wrote:
> Hi,
>
[snip]
>
> => explain analyze SELECT ip_src, port_src, ip_dst, port_dst,
> tcp_flags, ip_proto,SUM("bytes"),SUM("packets"),SUM("flows") FROM
> "acct_2010_25" WHERE "stamp_inserted">='2010-06-20 10:10' AND
> "stamp_inserted"<'2010-06-21 10:10' G
Hi folks,
is there a general problem with raid10 performance postgresql on it?
We see very low performance on writes (2-3x slower than on less
performant servers). I wonder if it is solely problem of raid10
configuration, or if it is postgresql's thing.
Would moving WAL dir to separate disk help
18 matches
Mail list logo
