James Rogers kirjutas N, 02.10.2003 kell 23:44:
> On Thu, 2003-10-02 at 12:09, Hannu Krosing wrote:
> > So what you really need is the CLUSTER command to leave pages half-empty
> > and the tuple placement logic on inserts/updates to place new tuples
> > near the place where they would be placed by
Tom Lane <[EMAIL PROTECTED]> writes:
> >> I'd almost argue that we should change this message to an error
>
> > I agree.
>
> Motion proposed and seconded; any objections out there?
Uhm, doesn't the spec have anything to say about this?
I mean, the view sure looks like standard SQL on its face
Check her over and let me know if there are any problems ... will do a
full general announce tomorrow for it ...
---(end of broadcast)---
TIP 8: explain analyze is your friend
Hi guys,
If someone could help me with this, it would be cool. How do I query
the catalogs to find the underlying index for a constraint? (Assuming
the constraint is primary or unique)
Chris
---(end of broadcast)---
TIP 1: subscribe and unsub
I wonder if it's something to do with the tsearch trigger on food_foods?
Actually, it definitely seems to be the tsearch trigger. The deadlock
occurs on every table that uses tsearch trigger, and no table that doesn't.
It's probably not the tsearch trigger itself even, it's probably the
fact t
OK, I tried it again and it still seems buggy to me...
australia= begin;
BEGIN
australia=# select * from food_foods where food_id = 21 for update;
food_id | category_id | brand_id | source_id |description
| base | type | created | modified | water | kilojoules |
calories | pr
nconway=# create view baz (a,b) as select 'hello', 'world';
WARNING: column "a" has type "unknown"
DETAIL: Proceeding with relation creation anyway.
It's always done that, although the spelling of the notice has
varied over the years.
I'd almost argue that we should change this message to an er
I have returned from Washington, but one of my sons is in the hospital
with a mild pneumonia. I think he is coming home tomorrow, so I will
read all my email this weekend.
It might seems strange I am reporting this, but I went away a while ago
and didn't inform the hackers list, and some people
Noticed a few late commits ... will tag-n-bundle beta4 tonight around
midnight, which should give the mirrors a chance to pick it up ...
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Thu, Oct 02, 2003 at 10:09:12PM +0300, Hannu Krosing wrote:
> So what you really need is the CLUSTER command to leave pages half-empty
> and the tuple placement logic on inserts/updates to place new tuples
> near the place where they would be placed by CLUSTER. I.e. the code that
> does actual
On Thu, 2003-10-02 at 12:09, Hannu Krosing wrote:
> So what you really need is the CLUSTER command to leave pages half-empty
> and the tuple placement logic on inserts/updates to place new tuples
> near the place where they would be placed by CLUSTER. I.e. the code that
> does actual inserting shou
Neil Conway <[EMAIL PROTECTED]> writes:
> On Thu, 2003-10-02 at 10:16, Tom Lane wrote:
>> Neil Conway <[EMAIL PROTECTED]> writes:
>>> nconway=# create view baz (a,b) as select 'hello', 'world';
>>> WARNING: column "a" has type "unknown"
>>> DETAIL: Proceeding with relation creation anyway.
>> I'
On Thu, 2003-10-02 at 10:16, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > nconway=# create view baz (a,b) as select 'hello', 'world';
> > WARNING: column "a" has type "unknown"
> > DETAIL: Proceeding with relation creation anyway.
>
> It's always done that, although the spelling
Sean Chittenden <[EMAIL PROTECTED]> writes:
> 2) While testing the above, I noted that 65K blocks fail and 32K is as
> big as PostgreSQL can handle, for one reason or another.
15-bit offsets in page item ids.
> but, it seems as though the test at the bottom of
> RelationGetBufferForTuple():
> sho
James Rogers kirjutas N, 02.10.2003 kell 20:50:
> To give a real world example, a standard query on one of our tables that
> has not been CLUSTER-ed recently (i.e. within the last several days)
> generates an average of ~2,000 cache misses. Recently CLUSTER-ed, it
> generates ~0 cache misses on a
On Thu, Oct 02, 2003 at 10:47:06 -0700,
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Possible scenario for maintaining 7.3:
>
> Only one or two committers using a two stage cvs... one stage for
> testing (not including sandbox), one stage for commit.
> Scheduled releases based
Sorry, no benchmark results in this post, but I do have a few notes to
pass along for folks:
1) FreeBSD -devel port now has configurable block sizes
2) 65K blocks fail, I think erroneously
3) The size of the postmaster proc and friends explodes to 45MB
4) effective_cache_size is a bad name for a G
On Wed, 2003-10-01 at 08:37, Tom Lane wrote:
> I think you'd need to do some basic architectural work first. Right now
> we have a clean API for index access methods, but there is no comparable
> abstraction layer for heaps (tables). It'd probably be necessary to
> create such a layer in order to
On Wed, 2003-10-01 at 09:29, Alvaro Herrera wrote:
> On Wed, Oct 01, 2003 at 11:37:38AM -0400, Tom Lane wrote:
> > Hm, are you sure that smarter buffer management wouldn't serve the
> > purpose?
>
> It doesn't help when there a lot of access locality in searching. In my
> case I want to select so
Hello,
Possible scenario for maintaining 7.3:
Only one or two committers using a two stage cvs... one stage for
testing (not including sandbox), one stage for commit.
Scheduled releases based on non-critical fixes. Quarterly? Of course
critical fixes should be released as soon as plausible.
Tom Lane wrote:
David Blasby <[EMAIL PROTECTED]> writes:
The only real problem is that the user has to manual keep stats
up-to-date. Is there anyway to attach something to VACUUM ANALYSE?
The ANALYZE code is set up with the idea that there could be multiple
analysis methods and various kinds of s
David Blasby <[EMAIL PROTECTED]> writes:
> The only real problem is that the user has to manual keep stats
> up-to-date. Is there anyway to attach something to VACUUM ANALYSE?
The ANALYZE code is set up with the idea that there could be multiple
analysis methods and various kinds of stuff stored
Tom Lane wrote:
You may need to bite the bullet and try to devise some real selectivity
estimation techniques for your geometric operators. The stuff in
src/backend/utils/adt/geo_selfuncs.c at the moment is all just stubs :-(
I've already done this - it actually gives pretty accurate estimates.
B
Tom Lane kirjutas N, 02.10.2003 kell 17:30:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > What is going on here? Surely getting a FOR UPDATE row lock should
> > prevent another process getting an update lock?
> The behavior you describe would certainly be a bug, but you'll have to
>
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> What is going on here? Surely getting a FOR UPDATE row lock should
> prevent another process getting an update lock?
I could not duplicate your results. I did
regression=# create table tab(id int , blah int);
CREATE TABLE
regression=# inser
Neil Conway <[EMAIL PROTECTED]> writes:
> Is this a bug?
> nconway=# create view baz (a,b) as select 'hello', 'world';
> WARNING: column "a" has type "unknown"
> DETAIL: Proceeding with relation creation anyway.
It's always done that, although the spelling of the notice has
varied over the year
> For example, if you have a timestamp index and you routinely clean out
> all entries older than N-days-ago, you won't have a problem in 7.4.
> If your pattern is to delete nine out of every ten entries (maybe you
> drop minute-by-minute entries and keep only hourly entries after awhile)
> then y
On Thu, 2003-10-02 at 08:40, Greg Stark wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
>
> > Is this a bug?
> >
> > (using CVS code from yesterday)
> >
> > nconway=# create view baz (a,b) as select 'hello', 'world';
> > WARNING: column "a" has type "unknown"
> > DETAIL: Proceeding with relat
Hi guys,
I'm just trying to understand this situation:
Session 1
-
BEGIN;
SELECT * FROM tab WHERE id=1 FOR UPDATE;
Session 2
-
UPDATE tab SET blah=1 WHERE id=1;
Session 1
-
UPDATE tab SET blah=1 WHERE id=1;
ERROR: deadlock detected
Session 2
-
...update has gone t
On Wed, Oct 01, 2003 at 09:01:23PM -0400, Neil Conway wrote:
> On Wed, 2003-10-01 at 20:25, Jingren Zhou wrote:
> > From the document, it seems that PREPARE/EXECUTE works only in the same
> > session. I am wondering whether postgres can prepare a query (save the plan)
> > for difference backends
Christopher Browne <[EMAIL PROTECTED]> writes:
> I would, given an ideal world, prefer to be able to have a connection
> or two live during this to let me monitor the DB and even get an early
> peek at the data.
On that note, how hard would it be to implement a read-dirty mode in postgres?
Thi
Neil Conway <[EMAIL PROTECTED]> writes:
> Is this a bug?
>
> (using CVS code from yesterday)
>
> nconway=# create view baz (a,b) as select 'hello', 'world';
> WARNING: column "a" has type "unknown"
> DETAIL: Proceeding with relation creation anyway.
> WARNING: column "b" has type "unknown"
>
Is this a bug?
(using CVS code from yesterday)
nconway=# create view baz (a,b) as select 'hello', 'world';
WARNING: column "a" has type "unknown"
DETAIL: Proceeding with relation creation anyway.
WARNING: column "b" has type "unknown"
DETAIL: Proceeding with relation creation anyway.
CREATE V
33 matches
Mail list logo
