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 or
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,
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
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/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 res
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
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?
[...]
spellche
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:
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
Yes, I only used the 'disjoint representations for first-bytes and
not-first-bytes of MB characters' feature in UTF8. Other encodings
allows both [AB] and [BA] for MB character patterns. UTF8Match() does
not cope with those encodi
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Yes, I only used the 'disjoint representations for first-bytes and
> not-first-bytes of MB characters' feature in UTF8. Other encodings
> allows both [AB] and [BA] for MB character patterns. UTF8Match() does
> not cope with those encodings; If we have
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 propert
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 th
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
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 t
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 of May, or else we can j
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 o
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.
---
Gr
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?
---
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 paid
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 bitm
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 Takahir
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.
---
Gr
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
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 midd
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
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?
I
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Except that the entire point of this patch is to dumb down NextChar to
be the same as NextByte for UTF8 strings.
That's not what I see in (what I think is) the latest submission, which
includes thi
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Except that the entire point of this patch is to dumb down NextChar to
>> be the same as NextByte for UTF8 strings.
> That's not what I see in (what I think is) the latest submission, which
> includes this snippet:
[ scratches head.
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
> parame
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
> "pgfo
"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 UNIQU
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
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
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 corr
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
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 property
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.
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Ok, I have studied some more and I think I understand what's going on.
> AIUI, we are switching from some expensive char-wise comparisons to
> cheap byte-wise comparisons in the UTF8 case because we know that in
> UTF8 the magic characters ('_', '%' a
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 -
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
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 us
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
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 explai
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. Th
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 a
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 Replicat
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
futu
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
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 o
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 buf
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 st
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, UTF
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
"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 signal
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 PROTEC
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.
---
FA
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
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 wrote
58 matches
Mail list logo
