Jonah H. Harris wrote:
On Thu, Oct 23, 2008 at 8:44 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
True, it is a kludge but if it gives us 95% of the benfit with 10% of
the code, it is a win.
I'd say, optimistically, maybe 30-45% the benefit over a proper
multi-block read using O_DIRECT.
Let's
Jonah H. Harris wrote:
fadvise is a kludge.
I don't think it's a kludge at all. posix_fadvise() is a pretty nice and
clean interface to hint the kernel what pages you're going to access in
the near future. I can't immediately come up with a cleaner interface to
do that.
Compared to async I
We did discuss this in Ottawa and I beleive your comment was "the hint
is in the name" referring to posix_fadvise.
In any case both aio and posix_fadvise are specified by posix so I
don't see either as a problem on that front.
I don't think we can ignore any longer that we effectively can't
Based on what? I did test this and posted the data. The results I
posted showed that posix_fadvise on Linux performed nearly as well on
Linux as async I/O on Solaris on identical hardware.
More importantly it scaled with the number if drives. A 15 drive array
gets about 15x the performance
On 24 Oct 2008, at 04:31 AM, "Jonah H. Harris"
<[EMAIL PROTECTED]> wrote:
On Thu, Oct 23, 2008 at 10:36 PM, Greg Stark
<[EMAIL PROTECTED]> 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
On Fri, Oct 24, 2008 at 12:42 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> non-portable, requires more user-to-system CPU, ... need I go on?
>
> I'd be interested to know which of these proposals you claim *is*
> portable. The single biggest reason to reject 'em all is that
> they aren't.
Yes, that
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> On Thu, Oct 23, 2008 at 10:36 PM, Greg Stark
>> In what way is fadvise a kludge?
> non-portable, requires more user-to-system CPU, ... need I go on?
I'd be interested to know which of these proposals you claim *is*
portable. The single biggest reas
On Thu, Oct 23, 2008 at 10:36 PM, Greg Stark
<[EMAIL PROTECTED]> 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.
Hmm, then obviously you did something wrong, because my tests sh
On Thu, Oct 23, 2008 at 8:44 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> True, it is a kludge but if it gives us 95% of the benfit with 10% of
> the code, it is a win.
I'd say, optimistically, maybe 30-45% the benefit over a proper
multi-block read using O_DIRECT.
--
Jonah H. Harris, Senior D
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, but I am unsure we
need
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?
greg
On 24 Oct 2008, at 01:44 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Jonah H. Harris wrote:
On
We've occasionally talked about allowing pending-trigger-event lists to
spill to disk when there get to be so many events that it's a memory
problem. I'm not especially interested in doing that right now, but
I noticed recently that we could alleviate the problem a lot by adopting
a more compact r
Russell Smith wrote:
> Alvaro Herrera wrote:
> > While you're cleaning up SSL, how about the thread with this email on
> > it:
> >
> > 19212172.post%40talk.nabble.com
> >
> >
> Yeah, I mentioned this to Magnus this morning (my time) and he said
> Bruce was compiling a patch in time for the next
Alvaro Herrera wrote:
> While you're cleaning up SSL, how about the thread with this email on
> it:
>
> 19212172.post%40talk.nabble.com
>
>
Yeah, I mentioned this to Magnus this morning (my time) and he said
Bruce was compiling a patch in time for the next commit fest.
I'm not sure where it's a
Jonah H. Harris wrote:
> On Thu, Oct 23, 2008 at 4:53 PM, Greg Smith <[EMAIL PROTECTED]> wrote:
> >> I think the current plan is to use posix_advise() to allow parallel I/O,
> >> rather than async I/O becuase posix_advise() will require fewer code
> >> changes.
> >
> > These are not necessarily mut
Magnus Hagander wrote:
> I notice that there is a src/backend/libpq/README.SSL that contains a
> couple of copied emails in it (it even contains our end-of-broadcast
> message string!) And it contains a reply to the mail, with quoted stuff!
>
> In general, this seem to be some hints about how to u
On Thu, Oct 23, 2008 at 4:53 PM, Greg Smith <[EMAIL PROTECTED]> wrote:
>> I think the current plan is to use posix_advise() to allow parallel I/O,
>> rather than async I/O becuase posix_advise() will require fewer code
>> changes.
>
> These are not necessarily mutually exclusive designs. fadvise w
While you're cleaning up SSL, how about the thread with this email on
it:
19212172.post%40talk.nabble.com
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-hackers mailing list (
I notice that there is a src/backend/libpq/README.SSL that contains a
couple of copied emails in it (it even contains our end-of-broadcast
message string!) And it contains a reply to the mail, with quoted stuff!
In general, this seem to be some hints about how to use things. Things
that if we need
Bruce Momjian wrote:
> Magnus Hagander wrote:
>> Attached patch cleans up the certificate verification in libpq, and adds
>> a configuration paraqmeter to control it. The new parameter is
>> "sslverify", and can be set to:
>
> Because SSL offers both encryption and authentication, I wonder if we
>
On Thu, 23 Oct 2008, Bruce Momjian wrote:
I think the current plan is to use posix_advise() to allow parallel I/O,
rather than async I/O becuase posix_advise() will require fewer code
changes.
These are not necessarily mutually exclusive designs. fadvise works fine
on Linux, but as far as I
Julius Stroffek wrote:
> Hi All,
>
> we would like to start some work on improving the performance of
> PostgreSQL in a multi-CPU environment. Dano Vojtek is student at the
> Faculty of Mathematics and Physics of Charles university in Prague
> (http://www.mff.cuni.cz) and he is going to cover this
The sad thing us that I also did a patch for this and lost it. I think
it wouldn't be too hard to convert all the call sites in the backend
and provide a wrapper for other users.
greg
On 23 Oct 2008, at 08:59 PM, Kris Jurka <[EMAIL PROTECTED]> wrote:
On Thu, 23 Oct 2008, Tom Lane wrote:
Magnus Hagander wrote:
> Attached patch cleans up the certificate verification in libpq, and adds
> a configuration paraqmeter to control it. The new parameter is
> "sslverify", and can be set to:
Because SSL offers both encryption and authentication, I wonder if we
should call this "sslauthentica
On Mon, 2008-10-20 at 10:25 +0100, Simon Riggs wrote:
> What else do we need?
> * pg_freeze_recovery()
> * pg_unfreeze_recovery()
Two more functions
pg_freeze_recovery_cleanup()
pg_unfreeze_recovery_cleanup()
These would allow recovery to continue normally, except for row removal
operations
On Thu, 23 Oct 2008, Tom Lane wrote:
Well, aside from the gruntwork needed to convert all the core code that
still uses the old APIs, there's the prospect of breaking extension
modules that still use the old APIs. It's kind of annoying to have two
copies of that code, but less annoying than
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> Works fine for me, eg
> I think he's looking for something like:
> 5 IN (col1,col2,col3)
> resulting in a bitmap or of three index scans of three different indexes on
> col1, col2, and col3.
Ah, I see. It would
On Thu, 2008-10-23 at 04:38 +0100, Simon Riggs wrote:
> > That means that out of the four state transitions that are
> > disallowed by the original coding of that Assert, you are now having to
> > consider two as legal. I don't like that, and I like even less that
> > it's not even trying to det
On Thu, 2008-10-23 at 20:24 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Thu, 2008-10-23 at 19:21 +0300, Heikki Linnakangas wrote:
> >> You have other issues with those still, namely that
> >> table locks are not yet taken appropriately, so I'm not sure if this is
> >> worth worr
Everyone,
What people asking for psql scriptability really want, in my estimate,
is the ability to write "SQL plus some control structures" anywhere, in
the server, in the client, or so that they don't have to know where.
Commercial vendors have that: Oracle has PL/SQL as server-side language
Simon Riggs wrote:
On Thu, 2008-10-23 at 19:21 +0300, Heikki Linnakangas wrote:
You have other issues with those still, namely that
table locks are not yet taken appropriately, so I'm not sure if this is
worth worrying about until that's done.
Please explain. If you know of a correctness issu
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> I thought about that too. I admit I am not sure if this really works
>> portably; however I don't want to add a palloc() to that routine.
> It should work, AFAIK, but unaligned memcpy()s and write()s can be a
> significant
On Thu, 2008-10-23 at 19:21 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > It would also be possible to introduce a special tweak there which is
> > that if the block is not in cache, don't read it in at all. If its not
> > in cache we know that nobody has a pin on it, so don't need to
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> On Thu, Oct 23, 2008 at 06:04:43PM +0300, Peter Eisentraut wrote:
>> Yeah, excellent question. It seems completely unnecessary, but it is
>> surely there in the syntax diagram.
> Probably because many Unicode representations are done with "U+"
> foll
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Looking over it again, that's pretty much the only one I find. I checked
> against sslmode. Did you spot something else?
No, I just thought that it looked like too small a patch for adding
a new conn option, and complained as soon as I found something
Alvaro Herrera wrote:
ITAGAKI Takahiro wrote:
I have some comments about the double-buffering:
Since posting this patch I have realized that this implementation is
bogus. I'm now playing with WAL-logging hint bits though.
Yeah, the torn page + hint bit updates problem is the tough questi
On Thu, Oct 23, 2008 at 06:04:43PM +0300, Peter Eisentraut wrote:
>> Man that's ugly. Why the ampersand?
>
> Yeah, excellent question. It seems completely unnecessary, but it is
> surely there in the syntax diagram.
Probably because many Unicode representations are done with "U+"
followed by 4-
Simon Riggs wrote:
It would also be possible to introduce a special tweak there which is
that if the block is not in cache, don't read it in at all. If its not
in cache we know that nobody has a pin on it, so don't need to read it
in just to say "got the lock". That icing for later.
Heh, that's
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> The patch seems pretty far short of sufficient as far as supporting a
> new conninfo option goes --- for instance it appears to leak the string
> at disconnect. Check through all the references to some existing option
> field to see
ITAGAKI Takahiro wrote:
> I have some comments about the double-buffering:
Since posting this patch I have realized that this implementation is
bogus. I'm now playing with WAL-logging hint bits though. As to your
questions:
> - Are there any performance degradation because of addtional memcpy?
Magnus Hagander wrote:
> This patch adds a configuration option to pg_hba.conf for "clientcert".
> This makes it possible to have different client certificate requirements
> on different connections. It also makes sure that if you specify that
> you want client cert verification and the root store
Zdenek Kotala wrote:
> Alvaro Herrera napsal(a):
>> Agreed, I started doing that some time ago ... it doesn't seem all that
>> complicated.
>
> Do you have any half patch?
Couldn't find it here, sorry :-(
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQ
Koichi Suzuki wrote:
In terms of compress/decompress WAL in archive/restore, please take a
look at my project pglesslog,
http://pgfoundry.org/projects/pglesslog/
This project compresses WAL segment by replacing full page writes with
corresponding incremental logs. When restored, it inserts dum
In terms of compress/decompress WAL in archive/restore, please take a
look at my project pglesslog,
http://pgfoundry.org/projects/pglesslog/
This project compresses WAL segment by replacing full page writes with
corresponding incremental logs. When restored, it inserts dummy WAL
record to mainta
This patch adds a configuration option to pg_hba.conf for "clientcert".
This makes it possible to have different client certificate requirements
on different connections. It also makes sure that if you specify that
you want client cert verification and the root store isn't there, we
give an error i
Alvaro Herrera napsal(a):
Zdenek Kotala wrote:
Tom Lane napsal(a):
Well, aside from the gruntwork needed to convert all the core code that
still uses the old APIs, there's the prospect of breaking extension
modules that still use the old APIs. It's kind of annoying to have two
copies of that
Zdenek Kotala wrote:
> Tom Lane napsal(a):
>> Well, aside from the gruntwork needed to convert all the core code that
>> still uses the old APIs, there's the prospect of breaking extension
>> modules that still use the old APIs. It's kind of annoying to have two
>> copies of that code, but less a
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Tom Lane napsal(a):
>> Well, aside from the gruntwork needed to convert all the core code that
>> still uses the old APIs, there's the prospect of breaking extension
>> modules that still use the old APIs. It's kind of annoying to have two
>> copies of t
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Currently in heaptuple.c we have duplicated code. heap_deformtuple and
heap_formtuple are mark as a obsolete interface. Is any reason to have still
them? I know that they are still used on many places, but is there any stopper
to k
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> There are some other disadvantages for making a function call. You
> couldn't use that kind of literal in any other place where the parser
> calls for a string constant: role names, tablespace locations,
> passwords, copy delimiters, enum values, f
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Currently in heaptuple.c we have duplicated code. heap_deformtuple and
> heap_formtuple are mark as a obsolete interface. Is any reason to have still
> them? I know that they are still used on many places, but is there any
> stopper
> to keep these f
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
SQL has the following escape syntax for it:
U&'special character: \' [ UESCAPE '\' ]
Man that's ugly. Why the ampersand?
Yeah, excellent question. It seems completely unnecessary, but it is
surely there in the syntax dia
Hi All,
BTree Insert requires a data-structure called BTStack to report the
page splits that have happened in the leaf pages to non-leaf pages upwards.
It basically goes back and updates those non-leaf pages. But this will never
happen in a search operation. You never need to climb upwards f
Currently in heaptuple.c we have duplicated code. heap_deformtuple and
heap_formtuple are mark as a obsolete interface. Is any reason to have still
them? I know that they are still used on many places, but is there any stopper
to keep these function alive?
Zdenek
--
Zdenek
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Isn't the whole point of EXPLAIN to expose implementation artifacts in
> the first place?
Touche ... I withdraw the complaint.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> SQL has the following escape syntax for it:
> U&'special character: \' [ UESCAPE '\' ]
Man that's ugly. Why the ampersand? How do you propose to distinguish
this from a perfectly legitimate use of the & operator?
> 2. Convert this syntax to
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
It turns out you cannot EXPLAIN on CREATE TABLE AS, but it seems to work
fine if I extend the grammar as below:
This seems to me to be something that will look like a wart, not a
feature, from the user's point of view. You can't exp
Le jeudi 23 octobre 2008, Tom Lane a écrit :
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > It turns out you cannot EXPLAIN on CREATE TABLE AS, but it seems to work
> > fine if I extend the grammar as below:
>
> This seems to me to be something that will look like a wart, not a
> feature, from
Magnus Hagander wrote:
> This patch changes the options field of pg_hba.conf to take name/value
> pairs instead of a fixed string. This makes it a lot nicer to deal with
> auth methods that need more than one parameter, such as LDAP.
>
> While at it, it also adds map support to kerberos, gssapi an
On Wed, Oct 22, 2008 at 04:14:11PM -0700, Joshua Drake wrote:
>
> True enough, but a car doesn't roll without at least four wheels.
I'm not sure I agree: http://en.wikipedia.org/wiki/Image:1885Benz.jpg
(Sorry, I couldn't resist.)
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http:/
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> It turns out you cannot EXPLAIN on CREATE TABLE AS, but it seems to work
> fine if I extend the grammar as below:
This seems to me to be something that will look like a wart, not a
feature, from the user's point of view. You can't explain CREATE TAB
Hi,
On Wed, Oct 22, 2008 at 8:14 PM, Jaime Casanova <
[EMAIL PROTECTED]> wrote:
> just remembering that -patches is a dead list, so i'm sending this to
> -hackers where it will have more visibility...
>
> -- Forwarded message --
> On 10/22/08, Nikhil Sontakke <[EMAIL PROTECTED]> w
On Thu, 2008-10-23 at 14:29 +0300, Peter Eisentraut wrote:
> It turns out you cannot EXPLAIN on CREATE TABLE AS, but it seems to work
> fine if I extend the grammar as below:
Yes please.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgs
On Thu, 2008-10-23 at 13:40 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > The patch isn't ready to apply standalone because we need to include the
> > changes to XidInMVCCSnapshot() also, which would take a little while to
> > extract. Let me know if that is worth producing a standalon
It turns out you cannot EXPLAIN on CREATE TABLE AS, but it seems to work
fine if I extend the grammar as below:
ExplainableStmt:
SelectStmt
| InsertStmt
| UpdateStmt
| DeleteStmt
| DeclareCursorStmt
+ | CreateAsStmt
| ExecuteStmt
Simon Riggs wrote:
The patch isn't ready to apply standalone because we need to include the
changes to XidInMVCCSnapshot() also, which would take a little while to
extract. Let me know if that is worth producing a standalone patch for.
FWIW, this patch becomes a lot simpler if you don't change
On Thu, 2008-10-23 at 09:09 +0300, Heikki Linnakangas wrote:
> However, we require that in b-tree vacuum, you take a cleanup lock on
> *every* leaf page of the index, not only those that you modify. That's a
> problem, because there's no trace of such pages in the WAL.
OK, good. Thanks for the
I would like to add an escape mechanism to PostgreSQL for entering
arbitrary Unicode characters into string literals. We currently only
have the option of entering the character directly via the keyboard or
cut-and-paste, which is difficult for a number of reasons, such as when
the font doesn'
On Thu, 2008-10-23 at 08:40 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Wed, 2008-10-22 at 21:47 +0100, Simon Riggs wrote:
> >
> >> But once you reach 64 transactions, you'll need to write an extra WAL
> >> record for every subtransaction, which currently I've managed to avoid.
>
2008/10/23 Peter Eisentraut <[EMAIL PROTECTED]>:
> Magnus Hagander wrote:
>>
>> If you want full scripting, look at pgscript, one of this summers gsoc
>> projects. It'll ship in the next pgadmin and is also available as a
>> standalone executable.
>
> Yet another language?
it is more crazy - pgscr
Magnus Hagander wrote:
If you want full scripting, look at pgscript, one of this summers gsoc
projects. It'll ship in the next pgadmin and is also available as a
standalone executable.
Yet another language?
What people asking for psql scriptability really want, in my estimate,
is the ability
Pavel Stehule wrote:
2008/10/23 Greg Stark <[EMAIL PROTECTED]>:
For making psql fully scriptable I would think it would be smarter to embed
a full well-supported existing language rather than trying to invent a new
one.
plpgsql?
I think plpgsql is a pretty good example of the sort of disaste
2008/10/23 Greg Stark <[EMAIL PROTECTED]>:
> For making psql fully scriptable I would think it would be smarter to embed
> a full well-supported existing language rather than trying to invent a new
> one.
plpgsql?
regards
Pavel
>
> If we do want to to that I would suggest looking at lua which is
On 23 okt 2008, at 00.48, Alvaro Herrera <[EMAIL PROTECTED]>
wrote:
Josh Berkus wrote:
Hackers,
Just had a feature request from Wheeler, and I don't see why it
shouldn't
go on our todo list.
I think you're asking for more scriptability in psql. Personally I
think that would be a great
For making psql fully scriptable I would think it would be smarter to
embed a full well-supported existing language rather than trying to
invent a new one.
If we do want to to that I would suggest looking at lua which is
intended to be used this way.
greg
On 23 Oct 2008, at 05:45 AM, Tom
75 matches
Mail list logo
