As for this
http://www.postgresql.org/message-id/20130903125155.ga18...@awork2.anarazel.de
there eventually seems to be a consensus (I notice now the discussion
was off-list):
> On 2013-09-03 23:21:57 +0200, Antonin Houska wrote:
>> On 09/03/2013 02:51 PM, Andres Freund wrote:
>>
seems grotty and completely unlike the way we do things elsewhere
> (compare GIN indexes which have rbtrees inside them).
Perhaps you meant that GIN has B-tree inside. RBTree is in fact used by
GiST, but only as in-memory structure during the search - to get the
tuples sorted by distance.
//
While reading storage/lmgr/lock.c I noticed that the last (proc)
argument of LockCheckConflicts() is not referenced inside the function.
Is it just a remnant from older version?
// Antonin Houska (Tony)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On 09/03/2013 06:56 PM, Alvaro Herrera wrote:
>> +/*
>> + * Only the following suffixes are allowed. It's not
>> too useful to
>> + * restrict the rate to gigabytes: such a rate will
>> probably bring
>> + * signific
On 07/24/2013 09:20 AM, Antonin Houska wrote:
> Hello,
> the purpose of this patch is to limit impact of pg_backup on running
> server.
Attached is a new version. Server-side implementation this time.
Antonin Houska (Tony)
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src
o implement it for the next version of the patch. However the
pg_basebackup is different from VACUUM, CLUSTER, etc. in that it
retrieves the data directly from file system, as opposed to buffers. So
there seems to be little room here for utilization of (future)
'throttling infrastructure'
On 08/26/2013 02:33 PM, Craig Ringer wrote:
> On 08/26/2013 08:15 PM, Hannu Krosing wrote:
>> On 08/26/2013 12:50 PM, Antonin Houska wrote:
>>>> On 08/22/2013 03:33 PM, Craig Ringer wrote:
>>>>>> On 08/22/2013 01:39 PM, PostgreSQL - Hans-Jürgen Schönig
lsewhere in the thread, the client-side
throttling was chosen because it seemed to be less invasive. But the
discussion (including this your comment) keeps me no longer convinced
that it's the best way. I'll reconsider things.
// Antonin Houska (Tony)
--
Sent via pgsql-hackers mail
pe as opposed to that of the pseudotype.
Is there any misconception in this patch proposal?
// Antonin Houska (Tony)
diff --git a/src/backend/access/gin/ginget.c b/src/backend/access/gin/ginget.c
index cb17d38..9e1c665 100644
--- a/src/backend/access/gin/ginget.c
+++ b/src/backend/access/gin/ginge
to check if the diff is correct)
// Antonin Houska (Tony)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 07/31/2013 07:13 AM, Gibheer wrote:
Hi,
That is a really nice feature.
I don't pretend it's my idea, I just coded it. My boss proposed the
feature as such :-)
I took a first look at your patch and some empty lines you added (e.g. line 60
your patch). Can you remove
them?
Sure, will do in
Hello,
the purpose of this patch is to limit impact of pg_backup on running
server. Feedback is appreciated.
// Antonin Houska (Tony)
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index eb0c1d6..3b7ecfd 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
On 07/04/2013 06:11 PM, Antonin Houska wrote:
On 07/03/2013 08:32 PM, Tom Lane wrote:
Another possibility would be to keep the optimization, but disable it in
queries that use LATERAL. I don't much care for that though --- seems
too Rube Goldbergish, and in any case I have a lot less fai
On 07/10/2013 07:28 AM, Atri Sharma wrote:
I am not sure if the part you mentioned is inline with the case I am
talking about.
Can you please post an example of such a join removal? I mean a query
before and after the removal. Thanks,
//Tony
--
Sent via pgsql-hackers mailing list (pgsql-hac
(non-LATERAL) queries or rather
patterns where the ph_may_need optimization clearly appears to be
important sounds to me like a good SQL exercise, but I'm afraid I won't
have time for it in the next few days.
//Antonin Houska (Tony)
--
Sent via pgsql-hackers mailing list
The lower limit could also be used in initsplan.c:check_outerjoin_delay().
Is this worth a patch? It's not much coding but I'd appreciate some
feedback before I try to do anything.
Thanks,
Antonin Houska (Tony)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On 06/29/2013 11:00 AM, Heikki Linnakangas wrote:
On 27.06.2013 17:20, Antonin Houska wrote:
I was curious about the new layout of the data page, so I spent a while
looking into the code.
It's interesting, but I suspect 2 things are not o.k.:
* gindatapage.c:dataIsEnoughSpace() - 'i
expects aligned pointer.
* gindatapage.c:ginCheckPlaceToDataPageLeaf() - comment "if leaf data
page" should probably be "on a leaf data page" or so.
Regards,
Antonin Houska (Tony)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ubquery has gone
at earlier stage of the planning.
Regards,
Antonin Houska (Tony)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
problem itself or anything
else. You'll probably know better.
(4f14c86d7434376b95477aeeb07fcc7272f4c47d is the last commit in my
environment)
Regards,
Antonin Houska (Tony)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
By chance (?) I got similar one today too, when dropping extension:
ERROR: could not open file "base/12623/12548": No such file or directory
I thought something might have gone wrong during Linux upgrade 2 days
ago, but it's not likely that we both have the issue.
I wonder if something is br
I'm also implementing an extension where direct access to non-fixed OIDs
(i.e. no catalog cache lookup by name) would be very helpful. I spent some
time thinking about a workaround that makes OID registry unnecessary.
How about the following?
1. Add a new varlena column to pg_proc catalog table,
On 07/06/2012 02:13 AM, Bruce Momjian wrote:
On Thu, Jul 05, 2012 at 10:10:08PM +0200, Antonin Houska wrote:
I found out by chance that \copyright command still contains 2011.
Perhaps documentation of "new year's day changes" needs to be
updated, if such exists.
What version
I found out by chance that \copyright command still contains 2011.
Perhaps documentation of "new year's day changes" needs to be updated,
if such exists.
Tony H.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
On 05/24/2012 12:46 AM, Tom Lane wrote:
Well, it's not per spec: what you did accepts queries that are invalid
per spec and are very likely to be errors rather than intentional
invocations of the LATERAL facility. This might be all right for
I think I saw queries where function is joined with
On 05/22/2012 09:31 PM, Robert Haas wrote:
This implementation looks different than I'd expect: I would have
thought that it would work by generating paths with param_info set to
the appropriate set of rels to provide the necessary values, rather
than inventing its own mechanism for forcing a n
Hello,
following this short discussion
http://archives.postgresql.org/message-id/4f5aa202.9020...@gmail.com
I gave it one more try and hacked the optimizer so that function can
become an inner relation in NL join, parametrized with values from the
outer relation.
I tried to explain my thoughts
On 03/10/2012 02:15 AM, Tom Lane wrote:
Um ... how do you get the subquery result rows to join to only the
correct rows of the other tables?
The subquery just restricts the set of rows that the function has to
evaluate. The main query is supposed to perform the join.
I understand, such a join ca
Hello,
in the related discussions mentioned on TODO list
http://archives.postgresql.org/pgsql-hackers/2009-09/msg00292.php
http://archives.postgresql.org/pgsql-hackers/2009-10/msg00991.php
(The 1st is rather on SQL, I didn't focuss on it yet.)
the implementation is discussed from optimizer/execu
101 - 129 of 129 matches
Mail list logo
