Mark Mielke wrote:
Josh Berkus wrote:
Count() on Oracle and MySQL is almost instantaneous, even for very
large tables. So why can't Postgres do what they do?
AFAIK the above claim is false for Oracle. They have the same
transactional issues we do.
Nope. Oracle's MVCC is implemen
Greg Smith <[EMAIL PROTECTED]> writes:
> I know when I'm playing with pgbench the primary key index on the big
> accounts table is 1/7 the size of the table, and when using that table
> heavily shared_buffers ends up being mostly filled with that index. The
> usage counts are so high on the inde
Josh Berkus wrote:
Count() on Oracle and MySQL is almost instantaneous, even for very
large tables. So why can't Postgres do what they do?
AFAIK the above claim is false for Oracle. They have the same
transactional issues we do.
Nope. Oracle's MVCC is implemented through rollback
On Fri, 7 Mar 2008, Tom Lane wrote:
Well, scanning an index to get a count might be significantly faster
than scanning the main table, but it's hardly "instantaneous". It's
still going to take time proportional to the table size.
If this is something that's happening regularly, you'd have to
VQQ7HE18
On Sat, Mar 8, 2008 at 9:50 AM, <[EMAIL PROTECTED]> wrote:
>A mensagem de email enviada para [EMAIL PROTECTED] confirmação para ser
> entregue. Por favor, responda este e-mail
> informando os caracteres que você vê na imagem abaixo.
>
> The email message sent to pgsql-performance@po
VE4TQQBN
--
With Best Regards,
Petchimuthulingam S
In a select query i have used the join conditions, will it affect query
performance.
Explicitly I didn't used the join command, Will it make any difference.
My Query is:
SELECT test_log.test_id, test_log.test_id, test_log.test_id,
user_details.first_name, group_details.group_name, site_details.s
Josh Berkus <[EMAIL PROTECTED]> writes:
> Tom,
>>> Count() on Oracle and MySQL is almost instantaneous, even for very
>>> large tables. So why can't Postgres do what they do?
>>
>> AFAIK the above claim is false for Oracle. They have the same
>> transactional issues we do.
> Nope. Oracle's MVCC
Tom,
> > Count() on Oracle and MySQL is almost instantaneous, even for very
> > large tables. So why can't Postgres do what they do?
>
> AFAIK the above claim is false for Oracle. They have the same
> transactional issues we do.
Nope. Oracle's MVCC is implemented through rollback segments, rath
Dave,
> "user_profile_pkey" PRIMARY KEY, btree (uid) CLUSTER
> "user_profile_name_idx" UNIQUE, btree (name varchar_pattern_ops)
> "user_profile_name_key" UNIQUE, btree (name)
> "user_profile_uploadcode_key" UNIQUE, btree (uploadcode)
> "user_profile_active_idx" btree (isact
Craig James wrote:
Tom Lane wrote:
Craig James <[EMAIL PROTECTED]> writes:
Count() on Oracle and MySQL is almost instantaneous, even for very
large tables. So why can't Postgres do what they do?
AFAIK the above claim is false for Oracle. They have the same
transactional issues we do.
My ex
Added to TODO:
* Improve referential integrity checks
http://archives.postgresql.org/pgsql-performance/2005-10/msg00458.php
---
Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > On Sat, Oct 29, 2005 at 09:4
Thanks to all for time and valuable help,
Pavel Rotek
2008/3/7, Bill Moran <[EMAIL PROTECTED]>:
>
> In response to "Pavel Rotek" <[EMAIL PROTECTED]>:
>
>
> > 2008/3/7, Tom Lane <[EMAIL PROTECTED]>:
>
>
> [snip]
>
>
> > > If you have to do it that way, you'll need very frequent vacuums on
> this
>
In response to "Pavel Rotek" <[EMAIL PROTECTED]>:
> 2008/3/7, Tom Lane <[EMAIL PROTECTED]>:
[snip]
> > If you have to do it that way, you'll need very frequent vacuums on this
> > table (not vacuum full, as noted already) to keep the toast space from
> > bloating too much. And make sure you've
"Pavel Rotek" <[EMAIL PROTECTED]> writes:
> 2008/3/7, Tom Lane <[EMAIL PROTECTED]>:
>> You mean that you build up the 5MB log entry by adding a few lines at a
>> time? That's going to consume horrid amounts of toast space, because
>> each time you add a few lines, an entire new toasted field value
2008/3/7, Matthew <[EMAIL PROTECTED]>:
>
> On Fri, 7 Mar 2008, Pavel Rotek wrote:
> > well, this will be the main problem... But... do uncomitted trasactions
> > affect toast space?
>
>
> I think the demonstrated answer to this is yes.
>
>
> > (begin tx, load previous log, do business action, appen
2008/3/7, Matthew <[EMAIL PROTECTED]>:
>
> > "Pavel Rotek" <[EMAIL PROTECTED]> writes:
> >> No i do not mean long running transactions... Update of log entry
> (update of
> >> row in dataaction) is performed in series of short transactions, but
> during
> >> short transaction there is a lot of chan
On Fri, 7 Mar 2008, Pavel Rotek wrote:
well, this will be the main problem... But... do uncomitted trasactions
affect toast space?
I think the demonstrated answer to this is yes.
(begin tx, load previous log, do business action, append new log, flush, do
business action, append new log, flush
2008/3/7, Tom Lane <[EMAIL PROTECTED]>:
>
> "Pavel Rotek" <[EMAIL PROTECTED]> writes:
> > No i do not mean long running transactions... Update of log entry
> (update of
> > row in dataaction) is performed in series of short transactions, but
> during
> > short transaction there is a lot of change l
"Pavel Rotek" <[EMAIL PROTECTED]> writes:
No i do not mean long running transactions... Update of log entry (update of
row in dataaction) is performed in series of short transactions, but during
short transaction there is a lot of change log value, flush, change log
value ,flush . change log
"Pavel Rotek" <[EMAIL PROTECTED]> writes:
> No i do not mean long running transactions... Update of log entry (update of
> row in dataaction) is performed in series of short transactions, but during
> short transaction there is a lot of change log value, flush, change log
> value ,flush . chang
Pavel Rotek escribió:
> 2008/3/7, Bill Moran <[EMAIL PROTECTED]>:
> > Don't do vacuum full on this table. Do frequent vacuums. The table will
> > bloat some, but not 10x the required size, once you find a reasonable
> > frequency for vacuums. You might find it practical to manually vacuum
> > t
How do we know in the output of expain command table or constraint names
so that while parsing each line of the output
we can able to recognise them and build the pictorial representation. for
example if you consider the following output
EXPLAIN select * from table1,table2 where
2008/3/7, Bill Moran <[EMAIL PROTECTED]>:
>
> In response to "Pavel Rotek" <[EMAIL PROTECTED]>:
>
> >
> > There are inserts and few updates (but what do you mean with update??
>
>
> He means adding or changing data in the table.
I understand, but i don't have deep understanding of mechanism, that
In response to "Pavel Rotek" <[EMAIL PROTECTED]>:
>
> There are inserts and few updates (but what do you mean with update??
He means adding or changing data in the table.
> committed update??, because there are many updates of the log attribute in
> trasaction, we do periodical flush during tran
On 6-Mar-08, at 9:30 PM, Stephen Denne wrote:
The strange thing of course is that the data is exactly the same for
both runs, the tables have not been changed between runs, and I did
them right after another. Even more strange is that the seq scan is
faster than the index scan.
It is not stra
Josh,
On 6-Mar-08, at 12:26 PM, Josh Berkus wrote:
Dave,
Below I have two almost identical queries. Strangely enough the one
that uses the index is slower ???
My first guess would be that records are highly correlated by DOB
and not at
all by name. However, it would help if you supplie
we just restored it to free 70G :-(
There are inserts and few updates (but what do you mean with update??
committed update??, because there are many updates of the log attribute in
trasaction, we do periodical flush during transaction), sum takes
approximately 1,2G, and i mean vacuum full (but the
Pavel Rotek wrote:
Hello,
i have problem with following table...
create table dataaction (
id INT4 not null,
log text,
primary key (id)
);
It is the table for storing results of long running jobs. The log attribute
takes approximately 5MB for one row (there is about 300 rows). My prob
On Fri, 7 Mar 2008, b wragg wrote:
Hi all,
I'm running the following query to match a supplied text string to an actual
place name which is recorded in a table with extra info like coordinates,
etc.
SELECT ts_rank_cd(textsearchable_index_col , query, 32 /* rank/(rank+1) */)
AS rank,*
FROM gaze
Hello,
i have problem with following table...
create table dataaction (
id INT4 not null,
log text,
primary key (id)
);
It is the table for storing results of long running jobs. The log attribute
takes approximately 5MB for one row (there is about 300 rows). My problem
is, that table da
31 matches
Mail list logo
