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
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
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
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
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
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
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
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
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
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 user dbname
--
Douglas J Hunley (doug at hunley.homeip.net) - Linux User
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
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)
role
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
[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 you're
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
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
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, does it
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. Breaking
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 be
about
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 way
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.
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, 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 NOT IN
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
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:
[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 you
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.
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
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 |
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 default
30 matches
Mail list logo
