Hmm, somehow I removed some recipients, especially the
list. Sorry for the duplicate.
-
Sorry, I've been back. Thank you for the comment.
> Do you have any insight into where I would pass the custom row fetches from
> the table struct to the scan struct?
Yeah it's one simple way to tune it,
sam.saffron wrote
> I have this query:
>
> select * from topics
> order by case when id=1 then 0 else 1 end, bumped_at desc
> limit 30
>
> It works fine, bumps id 1 to the front of the sort fine but is
> terribly inefficient and scans
>
> OTH
>
> "select * from topics where id = 1" is super fas
I have this query:
select * from topics
order by case when id=1 then 0 else 1 end, bumped_at desc
limit 30
It works fine, bumps id 1 to the front of the sort fine but is
terribly inefficient and scans
OTH
"select * from topics where id = 1" is super fast
"select * from topics order by bumped_a
On 02/01/2015 08:10 PM, Tom Lane wrote:
> I propose that we go over to a policy of keeping in HEAD only release
> notes for actively maintained branches, and that each back branch should
> retain notes only for branches that were actively maintained when it split
> off from HEAD. This would keep a
Dilip kumar writes:
> There is some minor issue in psql documentations for \setenv
> Attached patch is fixing the same.
> Actual option
> \setenv NAME [VALUE] set or unset environment variable
> In document
> \setenv [ name [ value ] ] --> name is not optional so it should be like below
> \set
Tom Lane-2 wrote
> I propose that we go over to a policy of keeping in HEAD only release
> notes for actively maintained branches, and that each back branch should
> retain notes only for branches that were actively maintained when it split
> off from HEAD. This would keep about five years worth o
There is some minor issue in psql documentations for \setenv
Attached patch is fixing the same.
Actual option
\setenv NAME [VALUE] set or unset environment variable
In document
\setenv [ name [ value ] ] --> name is not optional so it should be like below
\setenv name [ value ]
Regards,
Dil
Hello, I received an report that pg_basebackup with "-X stream"
always exits with the following error.
> pg_basebackup: could not receive data from WAL stream: server closed the
> connection unexpectedly
> This probably means the server terminated abnormally
> before or while proc
Hi,
Attached does the following:
-* stmt->relation->relpersistence if the select namespace is temporary.
+* stmt->relation->relpersistence if the selected namespace is temporary.
Thanks,
Amit
diff --git a/src/backend/parser/parse_utilcmd.c b/src/backend/parser/parse_utilcmd.c
index 3ccdbb7..7540
I noticed that the release notes now constitute 25% of our SGML
documentation, by line count at least:
[postgres@sss1 sgml]$ wc *.sgml ref/*.sgml | tail -1
336338 1116259 11124003 total
[postgres@sss1 sgml]$ wc release-*.sgml | tail -1
85139 267417 2516545 total
Another way to measure it is
On Tue, Jan 27, 2015 at 9:50 AM, Robert Haas wrote:
> This developed a slight merge conflict. I've rebased the attached
> version, and I also took the step of getting rid of buf_table.c, as I
> think I proposed somewhere upthread. This avoids the overhead of
> constructing a BufferTag only to c
Hi all,
Coverity is pointing out that we are doing pointer-NULL checks on
things that cannot be NULL in decrypt_internal():
out:
- if (src)
- mbuf_free(src);
- if (ctx)
- pgp_free(ctx);
+ Assert(ctx != NULL && src != NULL && dst != NULL);
+ mbuf
Hi all,
In metaphone() we do the following:
/* return an empty string if we receive one */
if (!(str_i_len > 0))
PG_RETURN_TEXT_P(cstring_to_text(""));
if (str_i_len > MAX_METAPHONE_STRLEN)
ereport(ERROR,
(err
Hi,
A first (not actually that quick :() look through the patches to see
what actually happened in the last months. I didn't keep up with the
thread.
Generally the split into the individual commits doesn't seem to make
much sense to me. The commits individually (except the first) aren't
indivdiua
On Sun, Feb 01, 2015 at 10:50:24AM -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > At least writing `pg_config --sysconfdir` indicates that it's in an
> > installation-specific location, whereas hardcoding /etc will create
> > confusion when it's not actually there. (Incidentally, we use
>
Heikki Linnakangas writes:
> On 02/01/2015 03:56 PM, Martijn van Oosterhout wrote:
>> If you want the compiler to catch this, I don't see any way without
>> requiring the code to indicate specifically which local variables it
>> intends to use, or not using the locals at all by using a seperate
>>
Heikki Linnakangas writes:
> On 02/01/2015 04:56 PM, Tom Lane wrote:
>> Hm. My understanding of the situation was that the "norwegian-bokmal"
>> solution worked on some Windows versions but not others.
> I'm no Windows expert, but believe that it's not the Windows version
> you're running on th
On 02/01/2015 03:56 PM, Martijn van Oosterhout wrote:
If you want the compiler to catch this, I don't see any way without
requiring the code to indicate specifically which local variables it
intends to use, or not using the locals at all by using a seperate
cleanup function (as discussed elsewher
On 02/01/2015 04:56 PM, Tom Lane wrote:
Heikki Linnakangas writes:
On 01/31/2015 09:52 PM, Tom Lane wrote:
What advice do we need to give 9.4 users?
I just downloaded the 9.4 EDB Windows installer and tried installing it.
initdb fails with the same error that I got after upgrading to more
r
Heikki Linnakangas writes:
> On 01/31/2015 09:52 PM, Tom Lane wrote:
>> What advice do we need to give 9.4 users?
> I just downloaded the 9.4 EDB Windows installer and tried installing it.
> initdb fails with the same error that I got after upgrading to more
> recent MSVC version. "select versi
Peter Eisentraut writes:
> At least writing `pg_config --sysconfdir` indicates that it's in an
> installation-specific location, whereas hardcoding /etc will create
> confusion when it's not actually there. (Incidentally, we use
> /usr/local/pgsql/etc elsewhere in the documentation as a sample lo
Martijn van Oosterhout writes:
> Never mind, it doesn't work. It's not that GCC doesn't know setjmp() is
> special, it does (the returns_twice attribute). So GCC does the above
> effectivly itself. The problem is that local variables may be stored
> in memory over calls in the PG_TRY() block, vo
On 31/01/15 14:55, Roger Pack wrote:
[...]
Now, the reality is that GetNewOidWithIndex() is going to keep
incrementing the global OID counter until it finds an OID that isn't in
the toast table. That means that if you actually get anywhere close to
using 4B OIDs you're going to become extremely
On Sun, Jan 25, 2015 at 07:11:12PM -0500, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > On Sun, Jan 25, 2015 at 02:02:47PM -0500, Tom Lane wrote:
> > It's a bit of a long shot, but perhaps if you put something like:
>
> > asm volatile("":"":"":"memory")
>
> > at the beginning of the catch
On 01/31/2015 09:52 PM, Tom Lane wrote:
Heikki Linnakangas writes:
On 01/16/2015 07:05 PM, Heikki Linnakangas wrote:
On 01/16/2015 04:17 PM, Tom Lane wrote:
What instructions do you have in mind to give?
Ok, I have created a wiki page for these instructions:
http://wiki.postgresql.org/w
25 matches
Mail list logo
