sorry, forgot to mention our version, it's postgresql 8.2.3
-laser
> I have a table:
> webdigest=# \d wd_urlusermaps
> 表 "public.wd_urlusermaps"
> 字段名 | 类型 | 修饰词
> -+-+-
> id | integer | not null defaul
I have a table:
webdigest=# \d wd_urlusermaps
表 "public.wd_urlusermaps"
字段名 | 类型 | 修饰词
-+-+-
id | integer | not null default nextval('wd_urlusermaps_id_seq'::regclass)
urlid | integer | not null
tag | ch
On Wed, 6 Jun 2007, Steinar H. Gunderson wrote:
On Tue, Jun 05, 2007 at 05:59:25PM -0400, Tom Lane wrote:
I think the main argument for partitioning is when you are interested in
being able to drop whole partitions cheaply.
Wasn't there also talk about adding the ability to mark individual pa
On Tue, 5 Jun 2007, Tom Lane wrote:
[EMAIL PROTECTED] writes:
however I really don't understand why it is more efficiant to have a 5B
line table that you do a report/query against 0.1% of then it is to have
1000 different tables of 5M lines each and do a report/query against 100%
of.
Essentia
"Steven Flatt" <[EMAIL PROTECTED]> writes:
> Is there any estimation as to if/when the fix will
> become available? I'm hoping this isn't going to be a showstopper in us
> moving to 8.2.
If you're feeling desperate you could revert this patch in your local
copy:
http://archives.postgresql.org/pgs
On Tue, Jun 05, 2007 at 05:59:25PM -0400, Tom Lane wrote:
> I think the main argument for partitioning is when you are interested in
> being able to drop whole partitions cheaply.
Wasn't there also talk about adding the ability to mark individual partitions
as read-only, thus bypassing MVCC and al
[EMAIL PROTECTED] writes:
> however I really don't understand why it is more efficiant to have a 5B
> line table that you do a report/query against 0.1% of then it is to have
> 1000 different tables of 5M lines each and do a report/query against 100%
> of.
Essentially what you are doing when yo
On Tue, Jun 05, 2007 at 05:30:14PM -0400, Steven Flatt wrote:
> (A) LEFT JOIN (B) ON col WHERE B.col IS NULL
>
> These queries are much slower on 8.2 than on 8.1 for what looks like the
> reason outlined above. I have rewritten a few key queries to be of the
> equivalent form:
>
> (A) WHERE col
On 5/18/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Yeah. 8.2 is estimating that the "nodeid IS NULL" condition will
discard all or nearly all the rows, presumably because there aren't any
null nodeid's in the underlying table --- it fails to consider that the
LEFT JOIN may inject some nulls. 8.1
On Tue, 5 Jun 2007, Gregory Stark wrote:
"Scott Marlowe" <[EMAIL PROTECTED]> writes:
Sorry, I think I initially read your response as "Postgres doesn't really get
any faster by breaking the tables up" without the "like that" part.
Well breaking up the tables like that or partitioning, either
Arjen van der Meijden wrote:
There are two solutions:
You can insert all data from tableB in tableA using a simple insert
select-statement like so:
INSERT INTO tabelA SELECT EmpId, EmpName FROM tabelB;
Or you can visually combine them without actually putting the records
in a single table. Th
Gregory Stark wrote:
"Scott Marlowe" <[EMAIL PROTECTED]> writes:
Sorry, I think I initially read your response as "Postgres doesn't really get
any faster by breaking the tables up" without the "like that" part.
Well breaking up the tables like that or partitioning, either way should b
"Scott Marlowe" <[EMAIL PROTECTED]> writes:
> Sorry, I think I initially read your response as "Postgres doesn't really get
> any faster by breaking the tables up" without the "like that" part.
Well breaking up the tables like that or partitioning, either way should be
about equivalent really. B
Thomas Andrews wrote:
On 6/5/07 12:48 PM, "Scott Marlowe" <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
On Mon, 4 Jun 2007, Scott Marlowe wrote:
Gregory Stark wrote:
"Thomas Andrews" <[EMAIL PROTECTED]> writes:
I guess my real question is, doe
So, partitioning in PSQL 8 is workable, but breaking up the table up into
actual separate tables is not?
Another solution we have proposed is having 'active' and 'completed' tables.
So, rather than thousands, we'd have four tables:
responders_active
responders_completed
responses_active
Find the attached Postgres.conf file. I am using 8.1 Version in Lab.
I haven't done any changes to this conf file to improve the performance.
What are the attributes needs to be modified in the conf file to improve the
performance?
I am looking forward for your assistance.
Regards,
Hanu
[EMAIL PROTECTED] wrote:
On Mon, 4 Jun 2007, Scott Marlowe wrote:
Gregory Stark wrote:
"Thomas Andrews" <[EMAIL PROTECTED]> writes:
> I guess my real question is, does it ever make sense to create
thousands > of
> tables like this?
>
Sometimes. But usually it's not a good idea.
What
On Tue, 5 Jun 2007, Markus Schiltknecht wrote:
I'm really wondering, if the RAID 6 of the ARECA 1260 hurts so badly
All of your disk performance tests look reasonable; certainly not slow
enough to cause the issue you're seeing. The only thing I've seen in this
thread that makes me slightly
On Monday 04 June 2007 17:11:23 Gregory Stark wrote:
> Those plans look like they have a lot of casts to text in them. How have
> you defined your indexes? Are your id columns really text?
project table:
Indexes:
"project_pk" PRIMARY KEY, btree (id)
"project_path" UNIQUE, btree (path)
rol
Hi,
Heikki Linnakangas wrote:
Maybe, TPC-C is very write-intensive. I don't know much about RAID
stuff, but I think you'd really benefit from a separate WAL drive. You
could try turning fsync=off to see if that makes a difference.
Hm.. good idea, I'll try that.
Oh, and how many connections a
On Monday 04 June 2007 17:17:03 Heikki Linnakangas wrote:
> And did you use the same encoding and locale? Text operations on
> multibyte encodings are much more expensive.
The db was created as:
createdb -E UNICODE -O
--
Douglas J Hunley (doug at hunley.homeip.net) - Linux User #174778
http://
Markus Schiltknecht wrote:
Hi,
Heikki Linnakangas wrote:
I still suspect there's something wrong with plans, I doubt you can
get that bad performance unless it's doing something really stupid.
Agreed, but I'm still looking for that really stupid thing... AFAICT,
there are really no seqscans
Hi,
Heikki Linnakangas wrote:
I still suspect there's something wrong with plans, I doubt you can get
that bad performance unless it's doing something really stupid.
Agreed, but I'm still looking for that really stupid thing... AFAICT,
there are really no seqscans..., see the pg_stat_user_ta
"Gauri Kanekar" <[EMAIL PROTECTED]> writes:
> Befor doing vaccum full on the database this query use to take less
> than 4min. But now after doing vacumming reindexing the tables it is
> taking 73mins.
Vacuum full is generally not necessary. You do need to ensure regular vacuum
is run frequently
On Tue, Jun 05, 2007 at 03:23:35PM +0530, Gauri Kanekar wrote:
> Befor doing vaccum full on the database this query use to take less
> than 4min. But now after doing vacumming reindexing the tables it is
> taking 73mins.
Did you analyze the table recently? Some of the selectivity estimates seem
q
Hi,
explain analyze SELECT am.campaign_id, am.optimize_type,
am.creative_id, am.optimize_by_days, am.impressions_delta,
am.clicks_delta, am.channel_code, am.cost,dm.allocation_map_id,
SUM(CASE dm.sqldate when 20070602 then dm.impressions_delivered else 0
end) as deliv_yest, SUM(CASE sign(20070526
Jason Lustig wrote:
I have some questions about the performance of certain types of SQL
statements.
What sort of speed increase is there usually with binding parameters
(and thus preparing statements) v. straight sql with interpolated
variables? Will Postgresql realize that the following quer
On Mon, Jun 04, 2007 at 11:18:30PM -0400, Jason Lustig wrote:
> I have some questions about the performance of certain types of SQL
> statements.
>
> What sort of speed increase is there usually with binding parameters
> (and thus preparing statements) v. straight sql with interpolated
> var
Hi,
explain analyze SELECT am.campaign_id, am.optimize_type,
am.creative_id, am.optimize_by_days, am.impressions_delta,
am.clicks_delta, am.channel_code, am.cost,dm.allocation_map_id,
SUM(CASE dm.sqldate when 20070602 then dm.impressions_delivered else 0
end) as deliv_yest, SUM(CASE sign(20070526
What sort of speed increase is there usually with binding parameters
(and thus preparing statements) v. straight sql with interpolated
variables? Will Postgresql realize that the following queries are
effectively the same (and thus re-use the query plan) or will it think
they are differen
30 matches
Mail list logo
