> "Tom" == Tom Lane writes:
[empty arrays and containment ops]
Tom> From what I understand of GIN's internal workings, this is
Tom> unfixable because there is nothing to make an index entry on
Tom> when looking at an empty array. Unless you know of a trick to
Tom> get around that, we'v
Robert Haas writes:
> On Sat, Apr 4, 2009 at 7:04 PM, Tom Lane wrote:
>> I'm not thrilled about adding a column to pg_attribute for this.
> What is the specific nature of your concern?
Actually, I'm more worried about the TupleDesc data structure than
the catalogs. There are TupleDescs all ove
On Sat, Apr 4, 2009 at 10:31 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Sat, Apr 4, 2009 at 7:04 PM, Tom Lane wrote:
>> > Robert Haas writes:
>> >> Per previous discussion.
>> >> http://archives.postgresql.org/message-id/8066.1229106...@sss.pgh.pa.us
>> >> http://archives.postgresql
Alvaro Herrera writes:
> FWIW it has been said that whoever is concerned about pg_attribute bloat
> should be first looking at getting rid of the redundant entries for
> system columns, for each and every table.
That's been overtaken by events, unfortunately: we now need those
entries to carry pe
Tom Lane wrote:
> I thought I would experiment with this a bit. I got past Python's
> "configure; make; make install" okay, but got no further than here
> with building PG:
Consequently, I have removed the Python 3.0 item from the open items
list and added a link to this thread to the TODO item
On Fri, Apr 3, 2009 at 5:10 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Apr 3, 2009 at 4:29 PM, Tom Lane wrote:
>>> Correct, but you've got the details all wrong. The real problem is that
>>> the planner might discard a join path hash(A,B) at level 2 because it
>>> loses compared to, s
Robert Haas escribió:
> On Sat, Apr 4, 2009 at 7:04 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> Per previous discussion.
> >> http://archives.postgresql.org/message-id/8066.1229106...@sss.pgh.pa.us
> >> http://archives.postgresql.org/message-id/603c8f070904021926g92eb55sdfc6814113395...@mail
On Sat, Apr 4, 2009 at 6:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> http://developer.postgresql.org/pgdocs/postgres/monitoring-stats.html
>> says: "Note: blocks_fetched minus blocks_hit gives the number of
>> kernel read() calls issued for the table, index, or database; but the
>> actual num
Chris Browne writes:
> j...@agliodbs.com (Josh Berkus) writes:
>> This one is also really bad, but probably only Doc-patchable.
>> However, can SQL/XML really be said to be core functionality if it
>> only works in UTF-8?
>> * BUG #4622: xpath only work in utf-8 server encoding
> Well, much of th
On Sat, Apr 4, 2009 at 7:04 PM, Tom Lane wrote:
> Robert Haas writes:
>> Per previous discussion.
>> http://archives.postgresql.org/message-id/8066.1229106...@sss.pgh.pa.us
>> http://archives.postgresql.org/message-id/603c8f070904021926g92eb55sdfc6814113395...@mail.gmail.com
>
> I'm not thrilled
If there are no objections, I'm going to remove the following items
from the list at
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items
finishing posix_fadvise patch
Push to TODO
change cardinality() for multi-dim arrays?
Drop; there's no consensus that this should be cha
I just got rid of the contrib/intarray duplicates of <@ and @>,
as we discussed here:
http://archives.postgresql.org/message-id/17021.1234474...@sss.pgh.pa.us
While I was testing this I realized that I wasn't getting quite the same
answers :-(. In particular, it seems that the core operators cons
Robert Haas writes:
> Per previous discussion.
> http://archives.postgresql.org/message-id/8066.1229106...@sss.pgh.pa.us
> http://archives.postgresql.org/message-id/603c8f070904021926g92eb55sdfc6814113395...@mail.gmail.com
I'm not thrilled about adding a column to pg_attribute for this.
Isn't the
Itagaki Takahiro writes:
> Vlad Arkhipov wrote:
>> Is it possible to print which key value is duplicated when 'Duplicate
>> key value violates unique constraint' occurs? Foreign key violation
>> error reports such kind of information.
> If no objection, I'd like to submit the patch to the next
Teodor Sigaev writes:
> [ fixes for the GIN stuff I complained about before ]
This all looks good to me, please apply. One little suggestion:
! /*
!* entryRes array is used for:
!* - as an argument for consistentFn
!* - entry->cur
Robert Haas writes:
> http://developer.postgresql.org/pgdocs/postgres/monitoring-stats.html
> says: "Note: blocks_fetched minus blocks_hit gives the number of
> kernel read() calls issued for the table, index, or database; but the
> actual number of physical reads is usually lower due to kernel-le
http://developer.postgresql.org/pgdocs/postgres/monitoring-stats.html
says: "Note: blocks_fetched minus blocks_hit gives the number of
kernel read() calls issued for the table, index, or database; but the
actual number of physical reads is usually lower due to kernel-level
buffering." This seems t
Simon Riggs writes:
> No need to wait for idle-in-transaction sessions during index builds.
> GetCurrentVirtualXIDs() specifically *includes* backends that have
> proc->xmin == InvalidTransactionId (0), but I'm not sure why.
Applied with the discussed tweaks. I also added some logic to make
Defi
On Sat, Apr 4, 2009 at 4:16 PM, Tom Lane wrote:
> Yeah. I did add a regression test for the specific case of '30 days'
> vs '1 month', which we know is a pain point for this particular data
> type. Generating values at random doesn't seem like it's really likely
> to teach us much though.
Yeah
Greg Stark writes:
> On Fri, Apr 3, 2009 at 10:46 PM, Tom Lane wrote:
>> The present implementation of interval_hash() is very carefully designed
>> and coded ... to meet the wrong specification :-(. What it should
>> be doing is producing equal hashcodes for values that interval_eq()
>> consider
Simon Riggs writes:
> On Fri, 2009-04-03 at 18:28 -0400, Tom Lane wrote:
>> So on third thought I think the patch logic is sound; but I think that
>> as documentation we had better add another bool parameter to
>> GetCurrentVirtualXIDs indicating whether it's okay to ignore procs
>> with xmin = 0.
Heikki Linnakangas writes:
> Tom Lane wrote:
>> The solution Heikki is proposing is to let the user choose immediate
>> or slow checkpoint. I agree that there's not much point in the latter
>> if you are using something dumb like tar to take the filesystem backup,
>> but maybe the user has someth
On Fri, Apr 3, 2009 at 10:46 PM, Tom Lane wrote:
> The present implementation of interval_hash() is very carefully designed
> and coded ... to meet the wrong specification :-(. What it should
> be doing is producing equal hashcodes for values that interval_eq()
> considers equal. The error is ex
Hi,
Le 3 avr. 09 à 22:29, Tom Lane a écrit :
Correct, but you've got the details all wrong. The real problem is
that
the planner might discard a join path hash(A,B) at level 2 because it
loses compared to, say, merge(A,B). But when we get to level three,
perhaps hash(hash(A,B),C) would've be
* After this new look at the code I think that matchPartialInPendingList
is completely broken. Surely it's an infinite loop if the
comparePartial function returns -1. I also don't understand why it
fixed
stops short of examining the tuple at maxoff, or for that matter why
it's doing any se
On Fri, 2009-04-03 at 18:28 -0400, Tom Lane wrote:
> So on third thought I think the patch logic is sound; but I think that
> as documentation we had better add another bool parameter to
> GetCurrentVirtualXIDs indicating whether it's okay to ignore procs
> with xmin = 0.
That sounds better thro
HI All,
I had gone through advantages of visibilitymap along with discussion on
thick index. I have a question.
when we have information about visibility of the data, does it make sense to
propagate values of expression stored in index through various slots of
execution tree?
It would be helpful w
Tom Lane wrote:
Bruce Momjian writes:
There was talk about making pg_start_backup do an immediate checkpoint
but there was some discussion that you wouldn't want an I/O storm from
pg_start_backup(). However, figuring you are going to do the tar backup
anyway, the pg_start_backup I/O seems triv
28 matches
Mail list logo
