On 10/10/2010 9:54 AM, Mladen Gogala wrote:
Unfortunately, the problem is in the rather primitive way PostgreSQL
does I/O. It didn't change in 9.0 so there is nothing you could gain by
upgrading. If you execute strace -o /tmp/pg.out -e read and inspect the file /tmp/pg.out when the query
finish
On 10/10/2010 2:55 PM, Mladen Gogala wrote:
On 10/10/2010 2:43 AM, Craig Ringer wrote:
Some of the other flavours of non-SQL databases, both those that've been
around forever (PICK/UniVerse/etc, Berkeley DB, Cache, etc) and those
that're new and fashionable Cassandra, CouchDB, etc, provide some
I have more than 130 records in crm table and I partioned the table with
deleted = 0 key.
It is working fine except that after partioion query is taking more time
than the previous one.
I already set constraint_exclusion = on; My DB version is Postgresql 8.1
I added the explain anayze for both
On Saturday 09 October 2010 23:56:15 Craig Ringer wrote:
> On 10/10/2010 11:02 AM, Neil Whelchel wrote:
> > On Saturday 09 October 2010 18:47:34 Scott Marlowe wrote:
> >> On Sat, Oct 9, 2010 at 5:26 PM, Neil Whelchel
> >
> > wrote:
> >>> I know that there haven been many discussions on the slownes
I already sent the mail earlier. but added wrong explain. So I mail it
again.
I have more than 130 records in crm table and I partioned the table with
deleted = 0 key.
It is working fine except that after partioion query is taking more time
than the previous one.
I already set constraint_exclu
On 10 October 2010 11:51, AI Rumman wrote:
> I already sent the mail earlier. but added wrong explain. So I mail it
> again.
>
> I have more than 130 records in crm table and I partioned the table with
> deleted = 0 key.
> It is working fine except that after partioion query is taking more tim
* Mladen Gogala:
> I have a logical problem with asynchronous commit. The "commit"
> command should instruct the database to make the outcome of the
> transaction permanent. The application should wait to see whether the
> commit was successful or not. Asynchronous behavior in the commit
> stateme
2010/10/10 Neil Whelchel
> On Saturday 09 October 2010 18:47:34 Scott Marlowe wrote:
> > On Sat, Oct 9, 2010 at 5:26 PM, Neil Whelchel
> wrote:
> > > I know that there haven been many discussions on the slowness of
> count(*)
> > > even when an index is involved because the visibility of the row
On 10/10/2010 7:45 AM, Florian Weimer wrote:
Some people use RDBMSs mostly for the*M* part, to get a consistent
administration experience across multiple applications. And even with
asynchronous commits, PostgreSQL will maintain a consistent state of
the database.
Both Postgres and Oracle ha
On 10/10/2010 6:29 PM, Neil Whelchel wrote:
On the other hand, I copied a table out of one of my production servers that
has about 60,000 rows with 6 columns (numeric, numeric, bool, bool, timestamp,
text). The first numeric column has numbers evenly spread between 0 and 100
and it is indexed. I
On 10/10/2010 6:29 AM, Neil Whelchel wrote:
On Saturday 09 October 2010 23:56:15 Craig Ringer wrote:
On 10/10/2010 11:02 AM, Neil Whelchel wrote:
On Saturday 09 October 2010 18:47:34 Scott Marlowe wrote:
On Sat, Oct 9, 2010 at 5:26 PM, Neil Whelchel
wrote:
I know that there haven been many
Craig Ringer wrote:
On 10/10/2010 9:54 AM, Mladen Gogala wrote:
Unfortunately, the problem is in the rather primitive way PostgreSQL
does I/O. It didn't change in 9.0 so there is nothing you could gain by
upgrading. If you execute strace -o /tmp/pg.out -e read and inspect the file /tmp/pg.o
On 10/10/2010 11:02 AM, Reid Thompson wrote:
On Sat, Oct 9, 2010 at 5:26 PM, Neil Whelchel
On the other hand, I copied a table out of one of my production servers that
has about 60,000 rows with 6 columns (numeric, numeric, bool, bool, timestamp,
text). The first numeric column has numbers eve
On Sunday 10 October 2010 05:02:03 Віталій Тимчишин wrote:
> 2010/10/10 Neil Whelchel
>
> > On Saturday 09 October 2010 18:47:34 Scott Marlowe wrote:
> > > On Sat, Oct 9, 2010 at 5:26 PM, Neil Whelchel
> >
> > wrote:
> > > > I know that there haven been many discussions on the slowness of
> >
On 10/11/2010 01:14 AM, Mladen Gogala wrote:
I can provide measurements, but from Oracle RDBMS. Postgres doesn't
allow tuning of that aspect, so no measurement can be done. Would the
numbers from Oracle RDBMS be acceptable?
Well, they'd tell me a lot about Oracle's performance as I/O chunk siz
On Sun, Oct 10, 2010 at 12:14 PM, Mladen Gogala
wrote:
>
>
>
> In other words, when I batched the sequential scan to do 128 blocks I/O, it
> was 4 times faster than when I did the single block I/O.
> Does that provide enough of an evidence and, if not, why not?
These numbers tell us nothing beca
On Mon, Oct 11, 2010 at 06:41:16AM +0800, Craig Ringer wrote:
> On 10/11/2010 01:14 AM, Mladen Gogala wrote:
>
>> I can provide measurements, but from Oracle RDBMS. Postgres doesn't
>> allow tuning of that aspect, so no measurement can be done. Would the
>> numbers from Oracle RDBMS be acceptable?
On 10/11/2010 08:27 AM, Joshua Tolley wrote:
One thing a test program would have to take into account is multiple
concurrent users. What speeds up the single user case may well hurt the
multi user case, and the behaviors that hurt single user cases may have been
put in place on purpose to allow
On 10/10/2010 8:27 PM, Joshua Tolley wrote:
It was asserted that reading bigger chunks would help performance; a response
suggested that, at least in Linux, setting readahead on a device would
essentially do the same thing. Or that's what I got from the thread, anyway.
I'm interested to know how
On Sun, Oct 10, 2010 at 11:14:43PM -0400, Mladen Gogala wrote:
> The fact is, however, that the question
> about slow sequential scan appears with some regularity on PostgreSQL
> forums.
Definitely. Whether that's because there's something pathologically wrong with
sequential scans, or just be
On 11/10/10 11:14, Mladen Gogala wrote:
> On 10/10/2010 8:27 PM, Joshua Tolley wrote:
>> It was asserted that reading bigger chunks would help performance; a
>> response
>> suggested that, at least in Linux, setting readahead on a device would
>> essentially do the same thing. Or that's what I got
On Sunday 10 October 2010 15:41:16 you wrote:
> On 10/11/2010 01:14 AM, Mladen Gogala wrote:
> > I can provide measurements, but from Oracle RDBMS. Postgres doesn't
> > allow tuning of that aspect, so no measurement can be done. Would the
> > numbers from Oracle RDBMS be acceptable?
>
> Well, they
I need to join two tales say TAB_A and TAB_B, where TAB_A is greater than
TAB_B in size and records.
Which Table should I put first in join order?
Any idea please.
On Mon, Oct 11, 2010 at 12:38 AM, AI Rumman wrote:
> I need to join two tales say TAB_A and TAB_B, where TAB_A is greater than
> TAB_B in size and records.
> Which Table should I put first in join order?
If it's a regular old inner join it doesn't matter, the query planner
will figure it out. If
24 matches
Mail list logo
