Attached is an updated version of the updateable cursors patch against
the latest cvs head.
Most of the changes in the patch are to make it sync with the changes in
CVS recently, for DECLARE CURSOR and EXPLAIN, as mentioned by Jaime in
his mail below.
Rgds,
Arul Shaji
FAST PostgreSQL
Hi,
Nope:
neilc=# create table t1 (a int, b int);
CREATE TABLE
neilc=# create unique index t1_a_idx on t1 ((a + b)) where (a 5);
CREATE INDEX
I just now realized that even though we allow the above. We do not allow:
pg=# create table t1 (a int, b int, unique(a+b));
nor the where clause
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Hello
I am not sure, but your solution will faill on scrollable cursors
(it's similar to holdable cursors). I miss part about limits in
documentation. Propably updatable cursors aren't supported by plpgsql
(and it's point to ToDo).
Regards
Pavel Stehule
2007/5/17, FAST PostgreSQL [EMAIL
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
This patch makes what was already a hack into a full-fledged crock (and
it's not just the self-doubting comments that make me distrust it).
I think we need to rip out this ad-hoc parameter change signaling code
and
Gregory Stark [EMAIL PROTECTED] writes:
It doesn't look like the timing of the ExecRescan is an issue at all. There
are plenty of nodes that Rescan their children much later than when they first
start up. Even Nested Loop does so.
Right, but separating the child rescan from the tuplestore
Itagaki,
I find this still fairly unclean. It certainly took me some time to get
me head around what's going on.
ISTM we should generate all these match functions from one body of code
plus some #define magic.
As I understand it, we have three possible encoding switches: Single
Byte,
NikhilS [EMAIL PROTECTED] writes:
I just now realized that even though we allow the above. We do not allow:
pg=# create table t1 (a int, b int, unique(a+b));
Any specific reason for this behaviour?
It'd be contrary to SQL spec. The UNIQUE constraint takes a list of
column names, full stop.
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
CK Tan wrote:
Hi,
I am submitting a patch for review that:
1. for small relation (smaller than 60% of
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Here is my proposed patch.
Actually, the original patch in this series was fairly horrid, and
things haven't been made better by the subsequent changes. It lacked
any comment explaining what it was doing; failed to comment on the
Alvaro Herrera [EMAIL PROTECTED] writes:
The part about actually advancing relfrozenxid is still not done though ...
Right. Are you intending to make that happen?
regards, tom lane
---(end of broadcast)---
TIP 2: Don't
On May 16, 2007, at 11:08 , Alvaro Herrera wrote:
I can't remember if I dropped something else.
Thanks, Alvaro. I've installed Hg and pulled from the site you
posted. When I get a few spare cycles I'll take a look.
Btw, we should look at localization for this in the not too distant
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
The part about actually advancing relfrozenxid is still not done though ...
Right. Are you intending to make that happen?
Yes.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication,
Attached is a new version of Simon's scan-resistant buffer manager
patch. It's not ready for committing yet because of a small issue I
found this morning (* see bottom), but here's a status update.
To recap, the basic idea is to use a small ring of buffers for large
scans like VACUUM, COPY
I wrote:
ISTM we should generate all these match functions from one body of
code plus some #define magic.
As I understand it, we have three possible encoding switches: Single
Byte, UTF8 and other Multi Byte Charsets, and two possible case
settings: case Sensitive and Case Insensitive.
Bruce Momjian wrote:
Heikki Linnakangas wrote:
We already played the name game on hackers. My original suggestion was
pgforensics. pgdiagfuncs and pginspect were also suggested, among
others. I'm still open to suggestions, though. Have any?
Something involving page would at least explain what
Heikki Linnakangas [EMAIL PROTECTED] writes:
I've completed a set of performance tests on a test server. The server
has 4 GB of RAM, of which 1 GB is used for shared_buffers.
Perhaps I'm misreading it, but these tests seem to show no improvement
worth spending any effort on --- some of the
Gavin Sherry wrote:
Hi all,
Attached is an updated bitmap index patch. It contains bug fixes, API
changes, binary changes (page identifier to distinguish it from other
indexes) and has been brought up to HEAD.
Very minor nitpick: I accidentally noticed that the Makefile in this
patch uses
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Pavel Stehule wrote:
Hello,
I actualised sql/psm patch:
added:
* last Tom's plpgsql patches (some fixes and
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I've completed a set of performance tests on a test server. The server
has 4 GB of RAM, of which 1 GB is used for shared_buffers.
Perhaps I'm misreading it, but these tests seem to show no improvement
worth spending any effort on
Wait a second ... I just thought of a counterexample that destroys the
entire concept. Consider the pattern 'A__B', which clearly is supposed
to match strings of four *characters*. With the proposed patch in
place, it would match strings of four *bytes*. Which is not the correct
behavior.
Tom Lane wrote:
UTF8 has disjoint representations for
first-bytes and not-first-bytes of MB characters, and thus it is
impossible to make a false match in which an MB pattern character is
matched to the end of one data character plus the start of another.
In character sets without that
Heikki Linnakangas [EMAIL PROTECTED] writes:
In any case, I do want this for VACUUMs to fix the WAL flush for every
dirty page problem. Maybe we should indeed drop the other aspects of
the patch and move on, I'm getting tired of this as well.
Can we devise a small patch that fixes that issue
Tom Lane wrote:
Wait a second ... I just thought of a counterexample that destroys the
entire concept. Consider the pattern 'A__B', which clearly is supposed
to match strings of four *characters*. With the proposed patch in
place, it would match strings of four *bytes*. Which is not the
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Wait a second ... I just thought of a counterexample that destroys the
entire concept. Consider the pattern 'A__B', which clearly is supposed
to match strings of four *characters*. With the proposed patch in
place, it would match
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Wait a second ... I just thought of a counterexample that destroys the
entire concept. Consider the pattern 'A__B', which clearly is supposed
to match strings of four *characters*. With the proposed patch in
Tom Lane [EMAIL PROTECTED] writes:
NikhilS [EMAIL PROTECTED] writes:
I just now realized that even though we allow the above. We do not allow:
pg=# create table t1 (a int, b int, unique(a+b));
Any specific reason for this behaviour?
It'd be contrary to SQL spec. The UNIQUE constraint
Applied. I also updated /contrib/README. Thanks.
---
Heikki Linnakangas wrote:
Bruce Momjian wrote:
Heikki Linnakangas wrote:
We already played the name game on hackers. My original suggestion was
pgforensics.
I wrote:
I am thinking that a cleaner fix is probably to make ExecRescanLimit do
the recompute_limits() bit immediately, so that the new limits are
available to the Sort node when it gets the rescan call. The comment
about timing of recompute_limits() is referring to the fact that
parameters
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
It'd be contrary to SQL spec. The UNIQUE constraint takes a list of
column names, full stop.
Does the SQL spec actually specify what happens if you provide an
non-compliant table definition like this?
It does not.
I wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Does the SQL spec actually specify what happens if you provide an
non-compliant table definition like this?
It does not. We could accept expressions there, and pray that the SQL
committee never extends the spec syntax in a direction
Andrew Dunstan [EMAIL PROTECTED] writes:
From my WIP patch, here's where the difference appears to be - note
that UTF8 branch has two NextByte calls at the bottom, unlike the other
branch:
Oh, I see: NextChar is still real but the patch is willing to have t
and p pointing into the middle of
Due to unfinished VACUUM:
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Gavin Sherry wrote:
Hi all,
Attached is an updated bitmap index patch. It contains
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
This needs additional changes for memory mangement and we don't have
time to do that for 8.3, Sorry:
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
ITAGAKI
Bruce Momjian wrote:
Due to unfinished VACUUM:
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
While we're at this, let's consider Heikki's patch for the streaming
indexscan API stuff. That patch was supposed to come from the bitmap
Tom Lane wrote:
* At a pattern backslash, it applies CHAREQ() but then advances
byte-by-byte over the matched characters (implicitly assuming that none
of these bytes will look like the magic characters). While that works
for backend-safe encodings, it seems a bit strange; you've already
I though the stream bitmaps was a cleanup of on-disk bitmaps, but I
think you are right that it was for GII too:
http://archives.postgresql.org/pgsql-patches/2007-03/msg00163.php
Heikki, can you clarify this and send us an updated version?
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Andrew Dunstan [EMAIL PROTECTED] writes:
Is it legal to follow escape by anything other than _ % or escape?
Certainly, but once you've compared the first byte you can handle any
remaining bytes via the main loop. And in fact the code is already
depending on being able to do that --- the use of
Neil Conway wrote:
On Mon, 2007-14-05 at 22:58 -0400, Neil Conway wrote:
Has a revised version of this patch been submitted?
In the absence of a revised patch, I can finish the feature myself, but
I won't get the free cycles until after PGCon. I can commit to getting
it done before the end
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
The part about actually advancing relfrozenxid is still not done though ...
Right. Are you intending to make that happen?
See attached patch. I'm intending to apply this sometime tomorrow.
Note that affecting CLUSTER changes code
No. It works with scrollable cursors. It will work for cursors/selects
which does not put the results in some store, such as WITH hold/group
by/order by etc But most of these restrictions apply for normal
'Select for update' anyway. (With the order by clause, the
implementation is as per
Tom Lane [EMAIL PROTECTED] wrote:
On the strength of this closer reading, I would say that the patch isn't
relying on UTF8's first-byte-vs-not-first-byte property after all.
All that it's relying on is that no MB character is a prefix of another
one, which seems like a necessary property for
Andrew Dunstan [EMAIL PROTECTED] writes:
Attached is my current WIP patch.
A few quick eyeball comments:
! static __inline__ int
Under *no* circumstances use __inline__, as it will certainly break
every non-gcc compiler. Use inline, which we #define appropriately
at need.
! *
Tom Lane wrote:
Under *no* circumstances use __inline__, as it will certainly break
every non-gcc compiler. Use inline, which we #define appropriately
at need.
OK. (this was from upstream patch.)
I thought we'd concluded that this explanation is pseudo-science?
[...]
On 5/17/07, FAST PostgreSQL [EMAIL PROTECTED] wrote:
No. It works with scrollable cursors. It will work for cursors/selects
which does not put the results in some store, such as WITH hold/group
by/order by etc But most of these restrictions apply for normal
'Select for update' anyway. (With
On 5/17/07, Jaime Casanova [EMAIL PROTECTED] wrote:
On 5/17/07, FAST PostgreSQL [EMAIL PROTECTED] wrote:
No. It works with scrollable cursors. It will work for cursors/selects
which does not put the results in some store, such as WITH hold/group
by/order by etc But most of these
On 5/16/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Jim C. Nasby wrote:
What about adding the ability to ask the FSM for a page that's near a
given page? That way if you did have to go to the FSM you could at least
try and insert close to the page you originally wanted.
Yeah, there's
On 5/17/07, Jaime Casanova [EMAIL PROTECTED] wrote:
On 5/16/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Jim C. Nasby wrote:
What about adding the ability to ask the FSM for a page that's near a
given page? That way if you did have to go to the FSM you could at least
try and insert
Hi Heikki,
On 5/17/07 10:28 AM, Heikki Linnakangas [EMAIL PROTECTED] wrote:
is also visible on larger scans that don't fit in cache with bigger I/O
hardware, and this patch would increase the max. I/O throughput that we
can handle on such hardware. I don't have such hardware available, I
2007/5/18, FAST PostgreSQL [EMAIL PROTECTED]:
No. It works with scrollable cursors. It will work for cursors/selects
which does not put the results in some store, such as WITH hold/group
by/order by etc But most of these restrictions apply for normal
'Select for update' anyway. (With the
52 matches
Mail list logo
