On Tue, Apr 26, 2011 at 2:25 AM, Andrew Dunstan wrote:
>
>
> On 04/25/2011 04:28 PM, Tom Lane wrote:
>
>> Andrew Dunstan writes:
>>
>>> On 04/25/2011 03:30 PM, Tom Lane wrote:
>>>
*Ouch*. Really? It's hard to believe that anyone would consider it
remotely usable for more than toy-siz
Patrick Earl writes:
> On Sun, May 1, 2011 at 9:00 PM, Tom Lane 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
On Sun, May 1, 2011 at 9:00 PM, Tom Lane 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 by someone els
Patrick Earl writes:
> On Sun, May 1, 2011 at 4:05 PM, Tom Lane 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 Column = 10
> The existing rows ar
-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
On Sun, May 1, 2011 at 1:14 PM, Kevin Grittner
wrote:
> Robert Treat wrote:
>> Tom Lane 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
On Sun, May 1, 2011 at 4:05 PM, Tom Lane wrote:
> Patrick Earl 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
>> concurr
Pavel Stehule 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
> and query is
Patrick Earl 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 PostgreSQL gets upset
"Kevin Grittner" 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 locks on the
> associat
On Sun, May 1, 2011 at 6:51 PM, Tom Lane wrote:
> Simon Riggs writes:
>> On Sat, Apr 30, 2011 at 11:48 PM, Tom Lane 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() withou
On Apr 30, 2011, at 10:21 PM, Tom Lane 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 one - before also.
On May 1, 2011, at 9:34 PM, "Kevin Grittner"
wrote:
> Joshua Berkus 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
Joshua Berkus 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 ready for committer
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 Francis
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 comfo
> 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
Simon Riggs writes:
> On Sat, Apr 30, 2011 at 11:48 PM, Tom Lane 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 delays inside the sorting
>> code
On Sat, Apr 30, 2011 at 11:48 PM, Tom Lane wrote:
> Jaime Casanova 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 lag, I propose the
>>> attache
[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 d
On Sat, Apr 30, 2011 at 5:33 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Joshua Berkus 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:
>> http://archives.postgresql.org/message-id/BANLkTimnjZNemdpqgK=8Mj=pzq3
Robert Treat wrote:
> Tom Lane 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 is
>> whether we be
Dne 1.5.2011 05:30, Tom Lane napsal(a):
> Tomas Vondra 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
On tor, 2011-04-28 at 00:03 -0400, Tom Lane wrote:
> Peter Eisentraut 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
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
25 matches
Mail list logo
