On K, 2005-07-13 at 11:53 +0100, Simon Riggs wrote:
We aren't able to exclude the parent table from the above query because
no Constraint was defined upon it. Since, in our example, the parent is
empty there will be little effect on the query performance. It would be
a mistake to attempt to
On K, 2005-07-13 at 16:10 +0100, Simon Riggs wrote:
On Wed, 2005-07-13 at 14:02 +0100, Richard Huxton wrote:
Sounds very useful - even for my small systems. Does it/would it work on
an ordinary table (for those cases currently using UNION ALL)?
I'm looking into that aspect right now.
I
On T, 2005-07-12 at 12:20 -0400, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
I try to state my reworked idea of concurrent indexing in a more clear
way:
The index build in done 2 transactions, need one new type of lock and a
new system column in pg_class to tell planner not
There were several reports of unable to read/write on
Pg8.0.x win32 port:
http://archives.postgresql.org/pgsql-bugs/2005-02/msg00181.php
I encounter this several times and finally I catch the
GetLastError() number. It is
32, ERROR_SHARING_VIOLATION
The process cannot access
On K, 2005-07-13 at 16:08 +0800, Christopher Kings-Lynne wrote:
Hi,
Does PostgreSQL do the following optimisation:
SELECT * FROM diary WHERE date = '2005-05-01' ORDER BY date;
or in fact even better (for my situation)
SELECT * FROM diary WHERE date BETWEEN '2005-05-01' AND
On N, 2005-07-14 at 00:13 +0300, Hannu Krosing wrote:
On K, 2005-07-13 at 11:53 +0100, Simon Riggs wrote:
We aren't able to exclude the parent table from the above query because
no Constraint was defined upon it. Since, in our example, the parent is
empty there will be little effect on
Hannu Krosing wrote:
On K, 2005-07-13 at 16:08 +0800, Christopher Kings-Lynne wrote:
Hi,
Does PostgreSQL do the following optimisation:
SELECT * FROM diary WHERE date = '2005-05-01' ORDER BY date;
or in fact even better (for my situation)
SELECT * FROM diary WHERE date BETWEEN
Christopher Kings-Lynne wrote:
Doesn't seem like it does:
usatest=# explain select * from users_myfoods_map where date='2004-11-21'
order by date;
QUERY PLAN
---
Sort (cost=17.17..17.48
Christopher Kings-Lynne said:
usatest=# explain select * from users_myfoods_map where
date='2004-11-21' order by date;
I assume that this is program generated SQL, as I hope a human would know
better than to write this. In which case, isn't the answer to improve the
generator rather than
My Solaris 9 box has the same regression failures for copy2, domain,
and alter_table in REL7_3_STABLE that caribou and stoat are showing
(geometry fails on those boxes as well, but passes on mine).
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=cariboudt=2005-07-14%2006:42:19
Magnus Hagander [EMAIL PROTECTED] writes
I suggest you try using Process Explorer from www.sysinternals.com to
figure out who has the file open. Most of the time it should be able to
tell you exactly who has locked the file - at least as long as it's done
from userspace. I'm not 100% sure on
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
further (anecdotal) data point: I have usually seen this after doing a
number of builds. Rebooting seems to cure the problem (and that's
happened today agin - I have just seen 2 builds work). Maybe some sort
of strange shmem
Qingqing wrote:
There were several reports of unable to read/write on Pg8.0.x win32
port:
http://archives.postgresql.org/pgsql-bugs/2005-02/msg00181.php
I encounter this several times and finally I catch the GetLastError()
number. It is
32, ERROR_SHARING_VIOLATION
The process
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Andrew Dunstan
Sent: 14 July 2005 13:35
To: Tom Lane
Cc: PostgreSQL-development
Subject: Re: [HACKERS] windows regression failure - prepared xacts
ON a related note, we need more Windows
On 7/14/05, Michael Paesold wrote:
Christopher Kings-Lynne wrote:
usatest=# explain select * from users_myfoods_map where date='2004-11-21'
order by date;
QUERY PLAN
---
Sort
Hannu Krosing [EMAIL PROTECTED] writes:
On K, 2005-07-13 at 16:08 +0800, Christopher Kings-Lynne wrote:
Does it know that the input to the sort routine is already sorted and
hence is a no-op?
Yes
No, but in most cases this will use an index and hence will assume that
the index is
Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Andrew Dunstan
Sent: 14 July 2005 13:35
To: Tom Lane
Cc: PostgreSQL-development
Subject: Re: [HACKERS] windows regression failure - prepared xacts
ON a related note, we need
-Original Message-
From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
Sent: 14 July 2005 14:36
To: Dave Page
Cc: Tom Lane; PostgreSQL-development
Subject: Re: [HACKERS] windows regression failure - prepared xacts
Short answer:
. your box will need to be able to contact
Michael Fuhr [EMAIL PROTECTED] writes:
psql segfaults a couple of times during the tests; here's a stack trace:
#0 0xff3655e8 in DLRemHead (l=0x0) at dllist.c:170
#1 0xff35d0c0 in PQnotifies (conn=0x4d970) at fe-exec.c:1560
#2 0x00019334 in SendQuery (query=0x4d970 ) at common.c:501
Argh!
Dave Page wrote:
Short answer:
. your box will need to be able to contact http://www.pgbuildfarm.org
either directly or via proxy, and it wiull need access to a CVS repo,
either the one at postgresql.org or a mirror (you can set up your own
mirror using CSVup on a linux or FBSD box).
-Original Message-
From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
Sent: 14 July 2005 15:17
To: Dave Page
Cc: Tom Lane; PostgreSQL-development
Subject: Re: [HACKERS] windows regression failure - prepared xacts
Yep, no problem there. Well, I say that - I find that if I
have
I've applied Alvaro's latest integrated-autovacuum patch. There are
still a number of loose ends to be dealt with before beta, though:
* Not all the functionality of the current contrib code seems to have
made it in. In particular I noted the sleep scaling factor is
missing, as well as the
On Sun, Apr 10, 2005 at 07:51:23PM +0200, Ramy M. Hassan wrote:
Hey Ramy,
I am currently working on porting SP-GiST to postgresql.
SP-GiST is an adaptation of GiST to support space partitioning trees (
http://www.cs.purdue.edu/homes/aref/dbsystems_files/SP-GiST/ )
The current standalone
Hi, All
I am new to devolopment of code, so maybe the question is quit simple.
I am trying to write a tools to convert a binary WAL file to a text file.
I want to use ReadRecord to get the record from the file and use RmgrTable[record-xl_rmid].rm_desc to interpreter the content. But the problem
On Fri, 2005-06-24 at 09:37 -0400, Tom Lane wrote:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
... So I'll post the new results:
checkpoint_ | writeback |
segments| cache | open_sync | fsync=false | O_DIRECT only |
fsync_direct | open_direct
On Thu, Jul 14, 2005 at 03:31:06PM +0900, clipper tokyo wrote:
Hi, All
I am new to devolopment of code, so maybe the question is quit simple.
I am trying to write a tools to convert a binary WAL file to a text file.
I think you could start by looking at Tom Lane's xlogdump. It's
This is great news! I will do what I can to continue improving the code
and address these concerns as best I can. Many of the items below will
need to be addressed by Alvaro, but I will comment where I think I have
something useful to say :-)
Tom Lane wrote:
I've applied Alvaro's latest
On Thu, Jul 14, 2005 at 10:52:56AM -0400, Tom Lane wrote:
I've applied Alvaro's latest integrated-autovacuum patch. There are
still a number of loose ends to be dealt with before beta, though:
Thanks, and again sorry for the bugs. The code for shutting the whole
thing down was not easy for me
On Fri, 2005-06-24 at 10:19 -0500, Jim C. Nasby wrote:
On Fri, Jun 24, 2005 at 09:37:23AM -0400, Tom Lane wrote:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
... So I'll post the new results:
checkpoint_ | writeback |
segments| cache | open_sync | fsync=false | O_DIRECT
Currently, the recommended way to ask have I already created a temp
table named foo is something like
select * from pg_class
where relname = 'foo' and pg_table_is_visible(oid);
If there's a possibility that a regular table named 'foo' exists,
then this isn't good enough and you
I did some testing and I think that I can confirm this - on my
workstation under Windows 2000 with latest CVS and gcc 3.2.3 it randomly
fails (it sometimes works and sometimes fails even with same binary) on
prepared_xacts and always fails on rules.
Tested 3 rebuilds and about 10 checks on
So it's not hardware and doesn't seem to be Windows version specific (my
tests were run on XPPro).
Looks like we have some major digging to do :-(
cheers
andrew
Petr Jelinek wrote:
I did some testing and I think that I can confirm this - on my
workstation under Windows 2000 with latest
Alvaro Herrera [EMAIL PROTECTED] writes:
Oh, is that right? Actually in the end I forgot about temp tables so I
didn't handle them specially, but now I remember that when I started
looking at Matthew's integration code I thought that temp tables should
be analyzed if they happen to have a lot
Tom Lane wrote:
Currently, the recommended way to ask have I already created a temp
table named foo is something like
select * from pg_class
where relname = 'foo' and pg_table_is_visible(oid);
If there's a possibility that a regular table named 'foo' exists,
then this isn't
Matthew T. O'Connor matthew@zeut.net writes:
Speaking of which, I think I mentioned this to Alvaro, but I guess it
just didn't make it in. The pg_autovacuum table should have a few
additional columns that allow setting vacuum delay settings on a per
table basis. I also think that there
Merlin Moncure [EMAIL PROTECTED] writes:
That said, I think what you are proposing is good since it causes less
log pollution. Although I would prefer to return the name of the
namespace, not the oid,
I thought about that, but it pushes you right back to having to do a
join with pg_namespace,
Tom Lane wrote:
Matthew T. O'Connor matthew@zeut.net writes:
Speaking of which, I think I mentioned this to Alvaro, but I guess it
just didn't make it in. The pg_autovacuum table should have a few
additional columns that allow setting vacuum delay settings on a per
table basis. I also
Alvaro Herrera [EMAIL PROTECTED] writes:
Thanks, and again sorry for the bugs. The code for shutting the whole
thing down was not easy for me to understand -- I think it should be
better documented. I can send a src/backend/postmaster/README file if
you think it's worth it; I'd document how
Hannu Krosing [EMAIL PROTECTED] writes:
It is not yet possible to specify that an inheritance parent has no
rows, and, if so, should always be excluded from the query.
I think that a simple CHECK(false) constraint should be enough for
this.
huh, that's clever.
CE checks are not made
Jeffrey W. Baker [EMAIL PROTECTED] writes:
The batteries on a caching RAID controller can run for days at a
stretch. It's not as dangerous as people make it sound. And anyone
running PG on software RAID is crazy.
Get back to us after your first hardware failure when your vendor says the
Greg Stark wrote:
Jeffrey W. Baker [EMAIL PROTECTED] writes:
The batteries on a caching RAID controller can run for days at a
stretch. It's not as dangerous as people make it sound. And anyone
running PG on software RAID is crazy.
Get back to us after your first hardware failure when
Tom Lane [EMAIL PROTECTED] writes:
I was thinking GUC settings only; is there a real use-case for
table-specific delay parameters? ISTM the point of the delay parameters
for autovac is to put a lid on its impact on interactive response. Seen
in that light, you do not care exactly which
On Thu, Jul 14, 2005 at 02:41:13PM +1000, Neil Conway wrote:
David Fetter wrote:
As background, I'd like to go over our policy of, The code patch
must be accompanied by any doc patches that it implies.
Although it is worth noting this policy is not religiously followed
anyway (e.g. the
That would respond to the abstraction concern in a more complete
fashion. I thought about that one too, but felt that the ability to
look at the whole pg_class row (and not only check existence) had some
value. Also, I've seen people doing things like
... where relname LIKE 'pattern'
On N, 2005-07-14 at 14:12 -0400, Tom Lane wrote:
Matthew T. O'Connor matthew@zeut.net writes:
Speaking of which, I think I mentioned this to Alvaro, but I guess it
just didn't make it in. The pg_autovacuum table should have a few
additional columns that allow setting vacuum delay
On Thu, 2005-07-14 at 00:13 +0300, Hannu Krosing wrote:
On K, 2005-07-13 at 11:53 +0100, Simon Riggs wrote:
We aren't able to exclude the parent table from the above query because
no Constraint was defined upon it. Since, in our example, the parent is
empty there will be little effect on
On Thu, 2005-07-14 at 15:30 -0400, Greg Stark wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
It is not yet possible to specify that an inheritance parent has no
rows, and, if so, should always be excluded from the query.
I think that a simple CHECK(false) constraint should be enough
* Tom Lane [EMAIL PROTECTED] [14.07.2005 01:00]:
sk_attno?
It seems, that sk_attno holds number of scankey itself.
I have table with 3 columns (a, b, c) and index (b, c).
For both selects (only 1 where clause in both of them):
select * from tab where b = ...
and
select * from tab
CE checks will not currently recognise STABLE functions within a query.
So WHERE clauses such as
DateKey CURRENT DATE
will not cause exclusion because CURRENT DATE is a STABLE function.
CE checks are not made when the parent table is involved in a join.
Is this also the case where
On N, 2005-07-14 at 21:29 +0100, Simon Riggs wrote:
On Thu, 2005-07-14 at 00:13 +0300, Hannu Krosing wrote:
On K, 2005-07-13 at 11:53 +0100, Simon Riggs wrote:
We aren't able to exclude the parent table from the above query because
no Constraint was defined upon it. Since, in our
On Fri, 2005-07-15 at 00:24 +0300, Hannu Krosing wrote:
On N, 2005-07-14 at 21:29 +0100, Simon Riggs wrote:
On Thu, 2005-07-14 at 00:13 +0300, Hannu Krosing wrote:
On K, 2005-07-13 at 11:53 +0100, Simon Riggs wrote:
We aren't able to exclude the parent table from the above query
On Fri, 2005-07-15 at 00:24 +0300, Hannu Krosing wrote:
Btw, not just UNION ALL, but also simple UNION, INTERSECT and EXCEPT
could probably be taught to use CE at some stage.
It turns out that to solve this problem you very nearly have to solve
the any table problem. Thats an extra argument in
I assume this is a TODO and just not in your first batch of work? It seems
like a pretty important piece eventually. Are there any fundamental
difficulties with handling joins eventually?
Its a reasonable size piece of work, and could not be reworked in time
for 8.1.
As you've said
Hannu,
My comment was too terse. What I meant was that you can't do dynamic
exclusion based upon the results of a join. i.e. PPUC2
but what about _static_ exlusion based on constraints ?
I mean if there is a left side table with say a single partition having
CHECK(id_order BETWEEN 1
Simon,
SELECT
FROM Fact, Dimension
WHERE Fact.Key = Dimension.Key
AND Dimension.DescriptiveField = 'Blah'
So, what happens with this:
SELECT
FROM Fact, Dimension
WHERE Fact.Key = Dimension.Key
AND Fact.part = 100;
With Fact defined with 3 partitions:
CHECK(Part BETWEEN1 AND 1000)
On R, 2005-07-15 at 00:24 +0300, Hannu Krosing wrote:
but what about _static_ exlusion based on constraints ?
I mean if there is a left side table with say a single partition having
CHECK(id_order BETWEEN 1 AND 1000)
(either originally or left after eliminating other by other
On Thu, 2005-07-14 at 15:16 -0700, Luke Lonergan wrote:
Simon,
SELECT
FROM Fact, Dimension
WHERE Fact.Key = Dimension.Key
AND Dimension.DescriptiveField = 'Blah'
So, what happens with this:
SELECT
FROM Fact, Dimension
WHERE Fact.Key = Dimension.Key
AND Fact.part = 100;
With
On Thu, 2005-07-14 at 15:07 -0700, Luke Lonergan wrote:
Hannu,
My comment was too terse. What I meant was that you can't do dynamic
exclusion based upon the results of a join. i.e. PPUC2
but what about _static_ exlusion based on constraints ?
I mean if there is a left side table
On Fri, 2005-07-15 at 01:20 +0300, Hannu Krosing wrote:
On R, 2005-07-15 at 00:24 +0300, Hannu Krosing wrote:
but what about _static_ exlusion based on constraints ?
I mean if there is a left side table with say a single partition having
CHECK(id_order BETWEEN 1 AND 1000)
Simon,
It's the first time I've thought to compare the constraint predicates on
joined tables based upon the join restriction. That's possible, but
would take some time to work out.
I've argued that such a construct is not common. I'm open to suggestions
about what *is* common...
I also
On Fri, 2005-07-15 at 00:24 +0300, Hannu Krosing wrote:
And thanks for the good work so far!
I think I should add: thanks for the good ideas so far.
Your ideas and challenges have been essential to progress to date, as
has been all the discussions and feedback.
This is the beginning of a
They should be completely portable (provided the script in src/test/mb runs
on that platform).
- Luke
On 7/12/05 10:54 AM, Andrew Dunstan [EMAIL PROTECTED] wrote:
Should we add the multibyte regression tests to the buildfarm test
suite? Does anyone know how portable they are? I guess
I assume that this is program generated SQL, as I hope a human would know
better than to write this. In which case, isn't the answer to improve the
generator rather than expect postgres to make up for its defficiencies?
Well, the issue in my case is we have user food diaries. Usually,
Does it know that the input to the sort routine is already sorted and
hence is a no-op?
Yes
No, but in most cases this will use an index and hence will assume that
the index is responsible for ordering.
OK, so what's going on here?
usa= explain select * from users_myfoods_map where
Seems worthwhile to me --- any objections? Any better ideas about a
name?
pg_session_temp_namespace()
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining
PostgreSQL hackers:
8.0.3 is working great for me on Mac OS X Tiger, but I do get a
segfault every time I exit pssql:
psql(7466) malloc: *** error for object 0x1806600: incorrect checksum
for freed object - object was probably modified after being freed,
break at szone_error to debug
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
OK, so what's going on here?
usa= explain select * from users_myfoods_map where user_id=1 and
date='2003-11-03' order by date;
QUERY PLAN
Well, date evidently isn't the high-order key of this index. But why
exactly are you worried about a sort of 2 rows?
Aha that's nailed it:
usa= explain select * from users_myfoods_map where user_id=1 and date
between '2003-11-03' and '2003-11-03' order by user_id, date;
68 matches
Mail list logo