On Thu, 2008-10-30 at 23:05 -0400, Robert Haas wrote:
> > Whatever timings you have are worth publishing.
>
> Here are the timings for copying the first ten million integers into a
> one-column table created in the same transaction, with and without the
> patch. As you can see, now that I've cor
On Wed, 2008-10-29 at 00:08 -0400, Robert Haas wrote:
> It's worth noting that this is the third version of this idea that has
> been submitted. Ian Caulfield submitted a patch to add this, and so
> did I. Someone should probably look at all three of them and compare.
>
If we include a function
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
> in the spanish list someone reports that the following function
> doesn't even compile:
> CREATE FUNCTION select_temporal(OUT valor integer) RETURNS SETOF record AS
> $BODY$
> begin
> return query select 1::integer;
> return;
> end;
> $BODY$
> LANGUAG
Hi,
in the spanish list someone reports that the following function
doesn't even compile:
CREATE FUNCTION select_temporal(OUT valor integer) RETURNS SETOF record AS
$BODY$
begin
return query select 1::integer;
return;
end;
$BODY$
LANGUAGE 'plpgsql' VOLATILE;
and this is the error message
ERROR:
> Whatever timings you have are worth publishing.
Here are the timings for copying the first ten million integers into a
one-column table created in the same transaction, with and without the
patch. As you can see, now that I've corrected my previous error of
not putting CREATE TABLE and COPY in
> You should try profiling the patch. You can count the invocations of the
> buffer access routines to check its all working in the right ratios.
*goes and learns how to do profile PostgreSQL*
OK, that was a good suggestion. It looks like part of my problem here
is that I didn't put the CREATE T
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 30, 2008 6:34 PM
> To: Dann Corbit
> Cc: [HACKERS]; Sherry Griffin
> Subject: Re: [HACKERS] Strange query behavior where clause produces
odd
> behavior on '>' query
>
> "Dann Corbit" <[EMAIL PROTECTED
Ooooh yeah. Time for some caffeine.
...Robert
On Thu, Oct 30, 2008 at 9:34 PM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> Robert Haas escribió:
>> > The closing semicolon is strictly speaking not allowed here. We could
>> > remove it, but that would probably upset pgindent?
>> >
>> > I rec
"Dann Corbit" <[EMAIL PROTECTED]> writes:
>> What encoding/locale are you using?
> Whatever the default encoding/locale is.
"Whatever" is the wrong answer here. I just finished verifying that the
sort order you're complaining about is the expected ordering in some
locales. I suggest that you
Robert Haas escribió:
> > The closing semicolon is strictly speaking not allowed here. We could
> > remove it, but that would probably upset pgindent?
> >
> > I recall that we used to have a bunch of similar problems with the AIX
> > compilers a long time ago. Does anyone recall the solution, and
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 30, 2008 5:31 PM
> To: Dann Corbit
> Cc: [HACKERS]; Sherry Griffin
> Subject: Re: [HACKERS] Strange query behavior where clause produces
odd
> behavior on '>' query
>
> "Dann Corbit" <[EMAIL PROTECTED
> The closing semicolon is strictly speaking not allowed here. We could
> remove it, but that would probably upset pgindent?
>
> I recall that we used to have a bunch of similar problems with the AIX
> compilers a long time ago. Does anyone recall the solution, and do we still
> care? (Note that
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> The following query:
> SELECT * FROM Customers_connxstore where customerid > 'specd'
> Returns the row containing Customers_connxstore.customerid == 'SPECD'
What encoding/locale are you using? And while I'm asking, which PG version?
The following query:
SELECT * FROM Customers_connxstore where customerid > 'specd'
Returns the row containing Customers_connxstore.customerid == 'SPECD'
I would expect to get that row if the query was:
SELECT * FROM Customers_connxstore where customerid >= 'specd'
The other operators (<, <=, >,
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> ... 3b sounds good until you
>> reflect that a genuinely variable chunk size would preclude random
>> access to sub-ranges of a toast value.
> Hm, Heikki had me convinced it wouldn't but now that I try to explain
Tom Lane <[EMAIL PROTECTED]> writes:
>> 2) Add page type (e.g. btree) and subtype (e.g. metapage) flag into page
>> header.
>> I think It will be useful when we will use share buffer for clog.
>
> I think this is a pretty bad idea, because it'll eat space on every page
> for data that is only us
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> 1) HeapTupleHeader modification
> typedef struct HeapTupleFields
> {
> TransactionId t_xmin; /* inserting xact ID */
> TransactionId t_xmax; /* deleting or locking xact ID */
> union
> {
>
Peter Eisentraut Wrote:
> If I read this right, SQL would allow writing
>
> TABLE foo;
Interesting; I managed to find it in the spec:
4) The
TABLE
is equivalent to the
( SELECT * FROM )
So going by that would the patch also have to support something like:
WITH a AS (SELECT * FROM b)
TABL
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Here's a patch. It seems pretty straightforward, I'll apply this
> tomorrow, barring objections. Note to self: bump the catalog version.
Looks sane in a fast once-over. I didn't cross-check the pg_cast.h
data changes, but that's what the regressio
Please find attached my current patch for automatic view update rules.
This is a stripped down version of my former patch discussed before 8.3
without CHECK OPTION support and less invasive changes to the rewriter
itself.
I'm currently cleaning up the code with all occurences of multiple ba
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> 3) TOAST modification
> a) TOAST table per attribute
> b) replace chunk id with offset+variable chunk size
> c) add column identification into first chunk
>
> Thats all. I think infomask/infomask2 shuffle flag should be done. TOAST
> modification c
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Yeah, a magical OID clearly has some issues. A new field in pg_cast is
the obvious alternative. How about adding a "castmethod" char field,
with values:
b = binary-compatible cast (CREATE CAST ... WITHOUT FUNCTION)
i = I/O coercion
Here is an updated posix_fadvise patch against CVS HEAD. It's my first patch
generated using git, yay. I remembered to strip out configure (WHY is that
STILL in CVS!?) and convert it to context diff, but if there's anything else
I've missed just shout.
Changes from before:
1) Based on discussion
It seems that we are going to bump Page Layout Version to version 5 (see CRC
patch for detail). Maybe it is good time to do some other changes. There is a
list of ideas (please, do not beat me :-). Some of them we discussed in Prato
and Greg maybe have more.
1) HeapTupleHeader modification
ty
ITAGAKI Takahiro wrote:
>> But is the idea of extending QueryDesc generally acceptable? Is it OK
>> to make a copy of the query string?
>
> The only thing I'm worried about is that QueryDesc lives longer than
> its queryText. Can I assume it never occurs?
>
I just finished validating this -- it
On Thu, Oct 30, 2008 at 03:41:17PM +, Gregory Stark wrote:
> The CRC is chosen such that if you CRC the resulting packet including the CRC
> you get a CRC of 0. That can be done for whatever offset the CRC appears at I
> believe.
IIRC, you calculate the CRC-32 of the page, then XOR it over whe
Alvaro Herrera wrote:
> Hmm, oh I see another problem here -- the bit is not restored when
> replayed heap_update's WAL record. I'm now wondering what other bits
> are set without much care about correctly restoring them during replay.
I'm now wondering whether it'd be easier to just ignore pd_f
On Thu, Oct 30, 2008 at 12:14 PM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> Gregory Stark escribió:
>
>> What I'm wondering though -- are we going to make CRCs mandatory? Or set
>> aside
>> the 4 bytes even if you're not using them? Because if the size of the page
>> header varies depending on w
> With session variables we could implement srf function in plpgsql like
> current C srf function. Like
>
> create or replace function foo()
> returns record as $$
> #option with_srf_context(datatype of srf context)
> begin
> return row(...);
> end;
> $$ language plpgsql;
Oh, sure - but what
This patch requires patch:
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
It add t_ver information into HeapTuple structure and add DatumGetHeapTuple
function which allows to reduce code on many places.
Zdenek
--
Zdenek Kotala Sun Microsystems
Pragu
Gregory Stark escribió:
> What I'm wondering though -- are we going to make CRCs mandatory? Or set aside
> the 4 bytes even if you're not using them? Because if the size of the page
> header varies depending on whether you're using CRCs that sounds like it would
> be quite a pain.
Not mandatory,
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Does it mean that these function are every time called with heap tuple or
> untoasted row type (composite data type)? What is purpose of these function.
Legacy support for third-party modules. They're really pretty much
deprecated but I don't foresee
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
By the way, do you need CRC as a first page member? Is it for future development
like CLOG integration into buffers? Why not put it on the end as and mark it as
a special? It will reduce space requirement when CRC is not enabled.
.
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> By the way, do you need CRC as a first page member? Is it for future
> development
> like CLOG integration into buffers? Why not put it on the end as and mark it
> as
> a special? It will reduce space requirement when CRC is not enabled.
... and make
I wrote:
> I'm currently going to have a look at just what it would take to support
> both lazy and eager evaluation in functions.c (independently of what
> syntax, if any, we settle on to expose the choice to the user). If it's
> either really awful or really easy we should know that before argui
Alvaro Herrera napsal(a):
Zdenek Kotala wrote:
Alvaro Herrera napsal(a):
Simon Riggs wrote:
But perhaps writing a single WAL record if you scan whole page and set
all bits at once. Then it makes sense in some cases.
So this is what I ended up doing; attached.
Please, DO NOT MOVE position of
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Ah, actually there's another alternative -- leave the checksum on its
> current position (start of struct) and move other members below
> pg_pagesize_version (leaning towards pd_tli and pd_flags). That'd leave
> the page version in the same position.
Hi,
Imre Geczy wrote:
> What kind of form or method must be used to patch that it can work correctly?
I finally got around writing some installation instructions:
http://www.postgres-r.org/documentation/installation
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
On Thu, Oct 30, 2008 at 11:27 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Jonah H. Harris" <[EMAIL PROTECTED]> writes:
>> On Thu, Oct 30, 2008 at 11:14 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>>> Well, yeah, but it has to be able to tell which version it's dealing
>>> with. I quite agree with Zdene
Jonah H. Harris napsal(a):
On Thu, Oct 30, 2008 at 10:33 AM, Zdenek Kotala <[EMAIL PROTECTED]> wrote:
Please, DO NOT MOVE position of page version in PageHeader structure! And
PG_PAGE_LAYOUT_VERSION should be bump to 5.
Umm, any in-place upgrade should be capable of handling changes to the
pag
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> On Thu, Oct 30, 2008 at 11:14 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Well, yeah, but it has to be able to tell which version it's dealing
>> with. I quite agree with Zdenek that keeping the version indicator
>> in a fixed location is appropriate.
Gregory Stark wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>
> > Alvaro Herrera wrote:
> >
> >> The "other hint bits" are:
> >>
> >> - LP_DEAD as used by the various callers of ItemIdMarkDead.
> >> - PD_PAGE_FULL
> >> - BTPageOpaque->btpo_flags and btpo_cycleid
> >>
> >> All of them are c
On Thu, Oct 30, 2008 at 11:14 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Jonah H. Harris" <[EMAIL PROTECTED]> writes:
>> On Thu, Oct 30, 2008 at 10:33 AM, Zdenek Kotala <[EMAIL PROTECTED]> wrote:
>>> Please, DO NOT MOVE position of page version in PageHeader structure! And
>>> PG_PAGE_LAYOUT_VERSIO
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> On Thu, Oct 30, 2008 at 10:33 AM, Zdenek Kotala <[EMAIL PROTECTED]> wrote:
>> Please, DO NOT MOVE position of page version in PageHeader structure! And
>> PG_PAGE_LAYOUT_VERSION should be bump to 5.
> Umm, any in-place upgrade should be capable of ha
Zdenek Kotala wrote:
> Alvaro Herrera napsal(a):
>> Simon Riggs wrote:
>>
>>> But perhaps writing a single WAL record if you scan whole page and set
>>> all bits at once. Then it makes sense in some cases.
>>
>> So this is what I ended up doing; attached.
>
> Please, DO NOT MOVE position of page ve
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Jonah H. Harris wrote:
>> On Thu, Oct 30, 2008 at 10:33 AM, Zdenek Kotala <[EMAIL PROTECTED]> wrote:
>>> Please, DO NOT MOVE position of page version in PageHeader structure! And
>>> PG_PAGE_LAYOUT_VERSION should be bump to 5.
>>
>> Umm, any in-place
Jonah H. Harris wrote:
On Thu, Oct 30, 2008 at 10:33 AM, Zdenek Kotala <[EMAIL PROTECTED]> wrote:
Please, DO NOT MOVE position of page version in PageHeader structure! And
PG_PAGE_LAYOUT_VERSION should be bump to 5.
Umm, any in-place upgrade should be capable of handling changes to the
page he
On Thu, Oct 30, 2008 at 10:33 AM, Zdenek Kotala <[EMAIL PROTECTED]> wrote:
> Please, DO NOT MOVE position of page version in PageHeader structure! And
> PG_PAGE_LAYOUT_VERSION should be bump to 5.
Umm, any in-place upgrade should be capable of handling changes to the
page header. Of, did I miss s
Alvaro Herrera napsal(a):
Simon Riggs wrote:
But perhaps writing a single WAL record if you scan whole page and set
all bits at once. Then it makes sense in some cases.
So this is what I ended up doing; attached.
There are some gotchas in this patch:
Please, DO NOT MOVE position of page v
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> CMPFUNC(tsquery_lt, res < 0);
> CMPFUNC(tsquery_le, res <= 0);
> CMPFUNC(tsquery_eq, res == 0);
> CMPFUNC(tsquery_ge, res >= 0);
> CMPFUNC(tsquery_gt, res > 0);
> CMPFUNC(tsquery_ne, res != 0);
> The closing semicolon is strictly speaking not allowed
Sun Studio is producing these compiler warnings (among others):
"tsquery_op.c", line 193: warning: syntax error: empty declaration
"tsquery_op.c", line 194: warning: syntax error: empty declaration
"tsquery_op.c", line 195: warning: syntax error: empty declaration
"tsquery_op.c", line 196:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>
>> The "other hint bits" are:
>>
>> - LP_DEAD as used by the various callers of ItemIdMarkDead.
>> - PD_PAGE_FULL
>> - BTPageOpaque->btpo_flags and btpo_cycleid
>>
>> All of them are changed with only SetBufferCommitInfoNeedsSa
>> (1) moving all of the patches committed prior to 11/1 to a separate
>> section or page
>
> Why?
To reduce clutter, but I don't feel strongly about it.
>> (2) sorting the pending patches by complexity or subject matter
>
> Sorting them by complexity would be great, if I thought I could do it.
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Yeah, a magical OID clearly has some issues. A new field in pg_cast is
the obvious alternative. How about adding a "castmethod" char field,
with values:
b = binary-compatible cast (CREATE CAST ... WITHOUT FUNCTION)
i = I/O coercion
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Yeah, a magical OID clearly has some issues. A new field in pg_cast is
> the obvious alternative. How about adding a "castmethod" char field,
> with values:
> b = binary-compatible cast (CREATE CAST ... WITHOUT FUNCTION)
> i = I/O coercion cast (th
(Resurrecting an old thread.)
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Patch attached. I'm using a magic OID "1" in pg_cast.castfunc field to
mark these extra I/O conversion casts.
Ugh. That's really unacceptable (doesn't it make the oidjoins
regression test fail?),
Y
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> The basic idea is to replace the custom loop in CopyReadLineText with
> memchr(), because memchr() is very fast. To make that possible, perform
> the client-server encoding conversion on each raw block that we read in,
> before splitting it into l
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Thu, 2008-10-30 at 08:30 -0400, Tom Lane wrote:
>> What about using the existing
>> syscache logic to re-derive inval information from watching the update
>> operations?
> That does sound possible, but it makes some big assumptions about
> transactional
Alvaro Herrera wrote:
> The "other hint bits" are:
>
> - LP_DEAD as used by the various callers of ItemIdMarkDead.
> - PD_PAGE_FULL
> - BTPageOpaque->btpo_flags and btpo_cycleid
>
> All of them are changed with only SetBufferCommitInfoNeedsSave being
> called afterwards.
I think we could get aw
Back in March, I played around with various hacks to improve COPY FROM
performance:
http://archives.postgresql.org/pgsql-patches/2008-03/msg00145.php
I got busy with other stuff, but I now got around to try what I planned
back then. I don't know if I have the time to finish this for 8.4, but
On Thu, 2008-10-30 at 08:30 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> >> We can't augment the commit/abort messages because
> >> we must cater for non-transactional invalidations also, plus commit
> >> xlrecs are already complex enough. So we log invalidations prior to
> >
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
GetAttributeByNum has first parameter as HeapTupleHeader, but most functions
use Datum and after that they call DatumGetHeapTupleHeader. The difference is
that DatumGetHeapTupleHeader performs detoast on tuple(row type).
Is it in
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> GetAttributeByNum has first parameter as HeapTupleHeader, but most functions
> use Datum and after that they call DatumGetHeapTupleHeader. The difference is
> that DatumGetHeapTupleHeader performs detoast on tuple(row type).
> Is it intention do not d
Simon Riggs <[EMAIL PROTECTED]> writes:
>> We can't augment the commit/abort messages because
>> we must cater for non-transactional invalidations also, plus commit
>> xlrecs are already complex enough. So we log invalidations prior to
>> commit, queue them and then trigger the send at commit (if i
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> If I read this right, SQL would allow writing
> TABLE foo;
> as a top-level command, equivalent to SELECT * FROM foo; (see production
> ). It can be used whereever a SELECT or VALUES can be used.
> This is probably about as useless as some of my ot
David Fetter <[EMAIL PROTECTED]> writes:
> On Wed, Oct 29, 2008 at 10:23:36PM -0400, Tom Lane wrote:
>> I would argue that it's already designed wrong if there's need for
>> PL-specific implementation effort.
> I'm not sure how else to do this. The current implementation returns
> char *, which d
Martin Pihlak <[EMAIL PROTECTED]> wrote:
> Attached is a patch that adds sourceText to QueryDesc.
It worked fine surprisingly :) . Internal and C functions don't use
executor, so we can ignore trivial function calls (ex. operators).
Furthermore, it is ok if QueryDesc doesn't have queryText
becau
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Hmm. I think an enum is better than a bitmask here. At the moment, we need
> three different modes of operation:
> 1. Read the page as usual, throw an error on corrupted page (ReadBuffer())
> 2. Read the page, zero page on corruption (this is new)
GetAttributeByNum has first parameter as HeapTupleHeader, but most functions
use Datum and after that they call DatumGetHeapTupleHeader. The difference is
that DatumGetHeapTupleHeader performs detoast on tuple(row type).
Is it intention do not detoast in these functions or it is a bug?
Bruce Momjian wrote:
Greg Stark wrote:
I couldn't get async I/O to work on Linux. That is it "worked" but
performed the same as reading one block at a time. On solaris the
situation is reversed.
In what way is fadvise a kludge?
I think he is saying AIO gives us more flexibility, b
On Tue, 2008-10-21 at 15:06 +0100, Simon Riggs wrote:
> We can't augment the commit/abort messages because
> we must cater for non-transactional invalidations also, plus commit
> xlrecs are already complex enough. So we log invalidations prior to
> commit, queue them and then trigger the send at
On Thu, 2008-10-30 at 09:57 +, Simon Riggs wrote:
> On Thu, 2008-10-30 at 10:40 +0200, Heikki Linnakangas wrote:
>
> > So, attached is a patch using an enum. Barring objections, I'll commit
> > this.
>
> I probably agree with the changes from reading your post, but I'd ask
> that you hang fi
On Thu, 2008-10-30 at 10:40 +0200, Heikki Linnakangas wrote:
> So, attached is a patch using an enum. Barring objections, I'll commit
> this.
I probably agree with the changes from reading your post, but I'd ask
that you hang fire on committing this for a few days.
It's just going to prevent Ko
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
The ReadBuffer() interface is already pretty complex, with all the
different variants. We should probably keep the good old ReadBuffer()
the same, for the sake of simplicity in the callers, but try to reduce
the number of other var
> I have put together a draft that describes a possible implementation:
> http://wiki.postgresql.org/wiki/SqlMedConnectionManager
>
I'll update this with an experimental patch. This implements:
* System catalogs for FDW, SERVER and USER MAPPING
* regserver data type for servers (convert from text
If I read this right, SQL would allow writing
TABLE foo;
as a top-level command, equivalent to SELECT * FROM foo; (see production
). It can be used whereever a SELECT or VALUES can be used.
This is probably about as useless as some of my other recent patches,
but the implementation is simpl
76 matches
Mail list logo
