Hi,I've created a table like this : CREATE TABLE tmp_A (c char,i int4);And another one CREATE TABLE tmp_B (i int4,ii int4);I then inerted a bit more than 19 million rows in each table (exactly the same number of rows in each).
The end result is that the physical size on disk used by table tmp_A
Am Donnerstag, 26. Januar 2006 11:06 schrieb Paul Mackay:
Hi,
I've created a table like this :
CREATE TABLE tmp_A (
c char,
i int4
);
And another one
CREATE TABLE tmp_B (
i int4,
ii int4
);
I then inerted a bit more than 19 million rows in each table (exactly the
same number of
For people installing PostgreSQL on Solaris with the new packaget, it
will show a greatly improved experience to get PostgreSQL up and running
which was quite a inhibitor in terms of Love at First Sight. This will
now help people familiar with Solaris have a great first impression of
Hey guys, how u been. This is quite a newbie
question, but I need to ask it. I'm trying to wrap my mind around the syntax of
join and why and when to use it. I understand the concept of making a query go
faster by creating indexes, but it seems that when I want data from multiple
tables
Hi All,
I have seen it on occasion that the total runtime reported
by explain analyze was much higher than the actual time the query needed to
complete. The differences in my case ranged between 20-120 seconds. Im
just curious if anyone else has experienced this and whether there is
First, this isn't really the right place to ask -- this forum is about
performance, not SQL syntax.
Second, this isn't a question anyone can answer in a reasonable length of time.
What you're asking for usually is taught in a class on relational database
theory, which is typically a semester
If I want my database to go faster, due to X then I would think that the
issue is about performance. I wasn't aware of a paticular constraint on X.
I have more that a rudementary understanding of what's going on here, I was
just hoping that someone could shed some light on the basic principal
[EMAIL PROTECTED] wrote:
If I want my database to go faster, due to X then I would think that
the issue is about performance. I wasn't aware of a paticular
constraint on X.
I have more that a rudementary understanding of what's going on here,
I was just hoping that someone could shed some
On Thu, 2006-01-26 at 09:50, Jozsef Szalay wrote:
Hi All,
I have seen it on occasion that the total runtime reported by explain
analyze was much higher than the actual time the query needed to
complete. The differences in my case ranged between 20-120 seconds.
I’m just curious if
[EMAIL PROTECTED] wrote:
If I want my database to go faster, due to X then I would think that the
issue is about performance. I wasn't aware of a paticular constraint on X.
You haven't asked a performance question yet though.
I have more that a rudementary understanding of what's going on
Jozsef Szalay wrote:
I have seen it on occasion that the total runtime reported by explain
analyze was much higher than the actual time the query needed to
complete. The differences in my case ranged between 20-120 seconds. I'm
just curious if anyone else has experienced this and whether there
Yes, that helps a great deal. Thank you so much.
- Original Message -
From: Richard Huxton dev@archonet.com
To: [EMAIL PROTECTED]
Cc: pgsql-performance@postgresql.org
Sent: Thursday, January 26, 2006 11:47 AM
Subject: Re: [PERFORM] Query optimization with X Y JOIN
[EMAIL PROTECTED]
It might be. I'm running on Fedora Linux kernel 2.6.5-1.358smp, GCC
3.3.3, glibc-2.3.3-27
-Original Message-
From: Richard Huxton [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 26, 2006 10:50 AM
To: Jozsef Szalay
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Incorrect
On Thu, Jan 26, 2006 at 04:49:59PM +, Richard Huxton wrote:
Jozsef Szalay wrote:
I have seen it on occasion that the total runtime reported by explain
analyze was much higher than the actual time the query needed to
complete. The differences in my case ranged between 20-120 seconds. I'm
On Thu, 2006-01-26 at 11:57, Michael Fuhr wrote:
On Thu, Jan 26, 2006 at 04:49:59PM +, Richard Huxton wrote:
Jozsef Szalay wrote:
I have seen it on occasion that the total runtime reported by explain
analyze was much higher than the actual time the query needed to
complete. The
Very good points thanks. In my case however, I was doing performance
tests and therefore I had a very controlled environment with a single
client (me) doing strictly read-only multi-join queries.
-Original Message-
From: Michael Fuhr [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 26,
At 01:27 PM 1/21/2006, Tom Lane wrote:
Ron [EMAIL PROTECTED] writes:
At 07:23 PM 1/20/2006, Tom Lane wrote:
Well, we're trying to split an index page that's gotten full into
two index pages, preferably with approximately equal numbers of items in
each new page (this isn't a hard requirement
Ron wrote:
At 01:27 PM 1/21/2006, Tom Lane wrote:
Ron [EMAIL PROTECTED] writes:
At 07:23 PM 1/20/2006, Tom Lane wrote:
Well, we're trying to split an index page that's gotten full into
two index pages, preferably with approximately equal numbers of items in
each new page (this isn't a
At 08:00 PM 1/26/2006, Alvaro Herrera wrote:
Ron wrote:
At 01:27 PM 1/21/2006, Tom Lane wrote:
Ron [EMAIL PROTECTED] writes:
At 07:23 PM 1/20/2006, Tom Lane wrote:
Well, we're trying to split an index page that's gotten full into
two index pages, preferably with approximately equal
Ron [EMAIL PROTECTED] writes:
We have two problems here.
The first is that the page splitting code for these indexes currently
has O(N^2) performance.
The second is that whatever solution we do use for this functionality,
we still need good performance during searches that use the index.
No,
You seem to have missed my point. I just gave a very clear
description of how to decide which bitmaps go in each of the two
buckets by reformulating the question into decide which bitmaps go
in each of =four= buckets.
The intent is to have two indexes, one optimized for one common class
of
At 11:13 PM 1/26/2006, Craig A. James wrote:
Ron,
I'll write to you privately, because these discussions can get messy
in public.
I'm responding to this missive publicly in an attempt to help the
discussion along. It is not my usual practice to respond to private
messages publicly, but
22 matches
Mail list logo
