On Wed, Jul 2, 2008 at 1:01 PM, samantha mahindrakar
<[EMAIL PROTECTED]> wrote:
> I ran the explain analyze.Here is what i got:
>
>
> "Group (cost=112266.37..112266.40 rows=1 width=56) (actual
> time=5583.399..5615.476 rows=13373 loops=1)"
> " -> Sort (cost=112266.37..112266.38 rows=1 width=56)
I ran the explain analyze.Here is what i got:
"Group (cost=112266.37..112266.40 rows=1 width=56) (actual
time=5583.399..5615.476 rows=13373 loops=1)"
" -> Sort (cost=112266.37..112266.38 rows=1 width=56) (actual
time=5583.382..5590.890 rows=13373 loops=1)"
"Sort Key: lane_data_07_08.l
On Wed, Jul 2, 2008 at 12:31 PM, Leví Teodoro da Silva
<[EMAIL PROTECTED]> wrote:
> Hi guys, How are you ?
>
>
> I am from Brazil and i work for a little company and it company is working
> is medium-big project and we want to use PostGree like the DataBase system,
> but i got some questions.
> I w
On Wed, 2008-07-02 at 15:31 -0300, Leví Teodoro da Silva wrote:
> we want to use PostGree like the DataBase system,
> but i got some questions.
First of all: Please learn the correct spelling: It is PostgreSQL, or
Postgres.
> I want to know if the PostGree has limitations about the concurrent
> a
Hi guys, How are you ?
I am from Brazil and i work for a little company and it company is working
is medium-big project and we want to use PostGree like the DataBase system,
but i got some questions.
I want to know if the PostGree has limitations about the concurrent access,
because a lot of peop
"Gauri Kanekar" <[EMAIL PROTECTED]> writes:
> Better HOT performance means 1st stat showed most of the updated tuples
> getting hot.
> But the 2nd stat showed that most of the updated tuples are NOT getting hot.
Well, as was noted upthread, you'd want to reduce the table fillfactor
(not index
2nd count include the 1st count also.
We have not restarted the DB since postgres 8.3 have been released.
Better HOT performance means 1st stat showed most of the updated tuples
getting hot.
But the 2nd stat showed that most of the updated tuples are NOT getting hot.
On Wed, Jul 2, 2008 at
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> On Wed, Jul 2, 2008 at 9:44 AM, Gauri Kanekar
>> Is there a way to check if the page is fill and the update is going on a new
>> page ??
> IIRC, I don't think so.
You could make your application check to see if the page part of a row's
CTID changes
On Wed, Jul 2, 2008 at 9:44 AM, Gauri Kanekar
<[EMAIL PROTECTED]> wrote:
> ok.. But we have set fill_factor = 80 for all the indexes on table1.
You need fill factor for the heap table, not the index.
> Is there a way to check if the page is fill and the update is going on a new
> page ??
IIRC, I
ok.. But we have set fill_factor = 80 for all the indexes on table1.
Is there a way to check if the page is fill and the update is going on a new
page ??
On Wed, Jul 2, 2008 at 6:59 PM, Jonah H. Harris <[EMAIL PROTECTED]>
wrote:
> On Wed, Jul 2, 2008 at 9:11 AM, Gauri Kanekar
> <[EMAIL PROTECT
On Wed, 2008-07-02 at 18:41 +0530, Gauri Kanekar wrote:
> hot have a limitation that it do not work if, the index column is
> updated.
It is one of the conditions -- it also needs to fit in the same block.
Regards,
--
Devrim GÜNDÜZ
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.or
Le Wednesday 02 July 2008, Jonah H. Harris a écrit :
> On Tue, Jul 1, 2008 at 8:18 PM, Jeffrey Baker <[EMAIL PROTECTED]> wrote:
> > Basically the ioDrive is smoking the RAID. The only real problem with
> > this benchmark is that the machine became CPU-limited rather quickly.
>
> That's traditional
On Wed, Jul 2, 2008 at 9:11 AM, Gauri Kanekar
<[EMAIL PROTECTED]> wrote:
> hot have a limitation that it do not work if, the index column is updated.
> But that not the case over here.
Another limitation is that HOT won't work if there's not enough space
to fit the update on the same page.
--
Jo
How does it indicate if the entries qualify for hot update ??
hot have a limitation that it do not work if, the index column is updated.
But that not the case over here.
On Wed, Jul 2, 2008 at 6:38 PM, Devrim GÜNDÜZ <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-07-02 at 18:01 +0530, Gauri Kanekar
On Wed, 2008-07-02 at 18:01 +0530, Gauri Kanekar wrote:
> Checked out the performance of Hot on 30th June :
>
> relname n_tup_ins n_tup_upd n_tup_del
> n_tup_hot_upd
> n_live_tup n_dead_tup *table1* *15509156* *2884653* *0* *2442823*
> *
> 15509158* *68046* table2 434585
No, Vacuum Full was not done, but auto_vacuum did click onto table1.
No cluster.
On Wed, Jul 2, 2008 at 6:10 PM, Jonah H. Harris <[EMAIL PROTECTED]>
wrote:
> On Wed, Jul 2, 2008 at 8:31 AM, Gauri Kanekar
> <[EMAIL PROTECTED]> wrote:
> > Performance of Hot was much better on 30June as compared t
On Wed, Jul 2, 2008 at 8:31 AM, Gauri Kanekar
<[EMAIL PROTECTED]> wrote:
> Performance of Hot was much better on 30June as compared to 2nd July.
Did you happen to VACUUM FULL or CLUSTER anything?
--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation | fax: 732
Hi all,
We have upgraded our database server to postgres 8.3.1 on 28th June.
Checked out the performance of Hot on 30th June :
relname n_tup_ins n_tup_upd n_tup_del n_tup_hot_upd
n_live_tup n_dead_tup *table1* *15509156* *2884653* *0* *2442823* *
15509158* *68046* ta
On Tue, Jul 1, 2008 at 8:18 PM, Jeffrey Baker <[EMAIL PROTECTED]> wrote:
> Basically the ioDrive is smoking the RAID. The only real problem with
> this benchmark is that the machine became CPU-limited rather quickly.
That's traditionally the problem with everything being in memory.
Unless the dat
On Tue, Jul 1, 2008 at 8:18 PM, Jeffrey Baker <[EMAIL PROTECTED]> wrote:
> I recently got my hands on a device called ioDrive from a company
> called Fusion-io. The ioDrive is essentially 80GB of flash on a PCI
> card. It has its own driver for Linux completely outside of the
> normal scsi/sata/s
20 matches
Mail list logo
