Hi guys,
Would it be useful to have a pg_get_prepared(name) function that returns
true or false depending on whether or not there is a prepared query of
that name?
Perhaps we could have a way of checking the parameter types of it as well?
(Also no-one replied to my PQescapeIdentifier suggest
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;
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
> -
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
psq
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 col
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 user
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,
99.%
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
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 journ
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 a
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 10
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 le
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
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 cons
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
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 BET
>> 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 sai
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
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
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 o
>>> 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 al
* 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 w
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 sh
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 effec
On N, 2005-07-14 at 14:12 -0400, Tom Lane wrote:
> "Matthew T. O'Connor" 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 p
> 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 'patte
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.
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
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
"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
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
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
Tom Lane wrote:
"Matthew T. O'Connor" 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_name
"Matthew T. O'Connor" 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 should be GUC
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 thi
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
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 CV
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 eac
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
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
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 m
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 in
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
in
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
> > +-
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 i
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
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 opt
> -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
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).
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
> -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 c
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 m
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 res
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
> -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 mor
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
> T
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 corr
""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
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=caribou&dt=2005-07-14%2006:42:19
http://www.pgbuil
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 ex
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 ro
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 '2005-05-01
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
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 '20
> 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 can
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 p
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
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 attemp
69 matches
Mail list logo
