Hello
I am solving a strange situation, where using a view is slower than
using same tables directly.
The view is defined as
CREATE VIEW v1 AS
SELECT *
FROM A
LEFT JOIN B
LEFT JOIN C
LEFT JOIN D
and query is
SELECT *
FROM T
On tor, 2011-04-28 at 00:03 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On ons, 2011-04-27 at 17:54 -0300, Alvaro Herrera wrote:
I take it that if I have a manpages/docbook.xsl in that path, it uses
that instead of trying to fetch it from sourceforge.
Exactly.
If
Dne 1.5.2011 05:30, Tom Lane napsal(a):
Tomas Vondra t...@fuzzy.cz writes:
testdb=# select bt_page_items('test_index', 3);
bt_page_items
--
(1,(1,1),8,f,f,)
(2,(2,1),12,f,f,ca 01 00 00)
(3,(4,1),12,f,f,93 03 00 00)
(3 rows)
I don't understand
Robert Treat r...@xzilla.net wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
CF #1: June 1-30
CF #2: August 1-31
CF #3: October 1-31
CF #4 (one week shortened CF): December 1-7
CF #5: January 1-31
I think the main thing we have to think about before choosing
On Sat, Apr 30, 2011 at 5:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Joshua Berkus j...@agliodbs.com wrote:
I just searched backwards on this thread and I can't find it.
I think he's talking about the bottom of this post:
[I previously posted this to pgsql-sql, but received no response as of
yet... it's more of a development team oriented message in any case.]
In ORMs like NHibernate, there are a few strategies for mapping
inheritance to SQL. One of these is Joined Subclass, which allows
for the elimination of
On Sat, Apr 30, 2011 at 11:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jaime Casanova ja...@2ndquadrant.com writes:
On Sat, Apr 30, 2011 at 1:19 PM, Gabriele Bartolini
I have noticed that during VACUUM FULL on reasonably big tables, replication
lag climbs. In order to smooth down the replication
Simon Riggs si...@2ndquadrant.com writes:
On Sat, Apr 30, 2011 at 11:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
A bigger objection to this patch is that it seems quite incomplete.
I'm not sure there's much point in adding delays to the first loop of
copy_heap_data() without also providing for
I think the main thing we have to think about before choosing is
whether
we believe that we can shorten the CFs at all. Josh's proposal had
3-week CFs after the first one, which makes it a lot easier to have a
fest in November or December, but only if you really can end it on
time.
I
Pavel,
Actually we had to solve a issue with slow SELECT. The problem was in
low value of JOIN_COLLAPSE_LIMITS. Can we increase a default of this
value. I checked some complex query, and planner needed about 200ms
for JOIN_COLLAPSE_LIMIT = 16. So some around 12 can be well.
I'm not
Dimitri,
I'll bet someone a fancy drink at a conference that this thread goes
to at least 100 posts.
Of course, if we all are to argue about this bet… :)
Darn! You've uncovered by sinister plan. Foiled again!
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
San Francisco
Joshua Berkus j...@agliodbs.com wrote:
Generally the last week only has 1-3 patches open
The last CF I managed the end of the third week looked like this:
http://archives.postgresql.org/pgsql-hackers/2010-08/msg00334.php
That is, we had 15 patches still pending out of 72 submitted:
9
On May 1, 2011, at 9:34 PM, Kevin Grittner kevin.gritt...@wicourts.gov
wrote:
Joshua Berkus j...@agliodbs.com wrote:
Generally the last week only has 1-3 patches open
The last CF I managed the end of the third week looked like this:
On Apr 30, 2011, at 10:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It also occurs to me to wonder if we could adjust the limit on-the-fly
based on noticing whether or not the query is prone to worst-case
behavior, ie how dense is the join connection graph.
I've had this thought - or a similar
On Sun, May 1, 2011 at 6:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Sat, Apr 30, 2011 at 11:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
A bigger objection to this patch is that it seems quite incomplete.
I'm not sure there's much point in adding delays
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
I haven't dug into ALTER INDEX enough to know whether it can ever
cause an index to be rebuilt. If so, we need to treat it like
DROP INDEX and REINDEX -- which should change all predicate locks
of any granularity on the index into relation
Patrick Earl pate...@patearl.net writes:
The query to get all the pets is as follows:
select * from Pet
left join Dog on Dog.Id = Pet.Id
left join Cat on Cat.Id = Pet.Id
Now suppose you want to lock to ensure that your Cat is not updated
concurrently. You add FOR UPDATE, but then
Pavel Stehule pavel.steh...@gmail.com writes:
I am solving a strange situation, where using a view is slower than
using same tables directly.
The view is defined as
CREATE VIEW v1 AS
SELECT *
FROM A
LEFT JOIN B
LEFT JOIN C
LEFT JOIN D
On Sun, May 1, 2011 at 4:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Patrick Earl pate...@patearl.net writes:
The query to get all the pets is as follows:
select * from Pet
left join Dog on Dog.Id = Pet.Id
left join Cat on Cat.Id = Pet.Id
Now suppose you want to lock to ensure that your Cat
On Sun, May 1, 2011 at 1:14 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Robert Treat r...@xzilla.net wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
CF #1: June 1-30
CF #2: August 1-31
CF #3: October 1-31
CF #4 (one week shortened CF): December 1-7
CF
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Joshua Berkus wrote:
I'm not comfortable with increasing the default, yet. While folks on
dedicated good hardware can handle a collapse of 10-12 joins, a lot
of people are running PostgreSQL on VMs these days whose real CPU
power is no
Patrick Earl pate...@patearl.net writes:
On Sun, May 1, 2011 at 4:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Quite. What would it mean to lock the absence of a row?
I would argue that SELECT FOR UPDATE never locks on the absence of a
row. For example, if I do:
SELECT * FROM Table WHERE
On Sun, May 1, 2011 at 9:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Addition of new rows certainly isn't supposed to be prevented by a
SELECT FOR UPDATE, but that's not the problem here. What I *do* expect
a SELECT FOR UPDATE to promise is that the rows it did return can't
change or be deleted
Patrick Earl pate...@patearl.net writes:
On Sun, May 1, 2011 at 9:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Addition of new rows certainly isn't supposed to be prevented by a
SELECT FOR UPDATE, but that's not the problem here. What I *do* expect
a SELECT FOR UPDATE to promise is that the rows
24 matches
Mail list logo
