I wrote:
> Attached is the remainder of the patch with relatively minor fixes.
> The main change I made is to get rid of the changes in gincostestimate;
> I agree with Robert that it's probably inappropriate to consider the
> current pending-list size during planning. I haven't really reviewed
> a
Oleg Bartunov writes:
> I'm also wonder if we're on the right way, since the only serious
> issue with indexscan was possible problem with slaves, but read-only slaves
> delayed to 8.5, so this is not an issue now. In 8.5 development cycle we'll
> certainly return to this issue, so why do we disa
On Thu, 5 Mar 2009, Robert Haas wrote:
On Thu, Mar 5, 2009 at 6:35 PM, Tom Lane wrote:
Attached is the remainder of the patch with relatively minor fixes.
The main change I made is to get rid of the changes in gincostestimate;
I agree with Robert that it's probably inappropriate to consider th
On Thu, Mar 5, 2009 at 6:35 PM, Tom Lane wrote:
> Attached is the remainder of the patch with relatively minor fixes.
> The main change I made is to get rid of the changes in gincostestimate;
> I agree with Robert that it's probably inappropriate to consider the
> current pending-list size during
Teodor Sigaev writes:
> Changes since 28.2
> (http://archives.postgresql.org/message-id/499b0ffa.8040...@sigaev.ru)
> - fixes/changes pointed by Robert
> (http://archives.postgresql.org/pgsql-hackers/2009-02/msg00987.php)
> - gingetbitmap will never throw error about lossiness of bitmap, it wil
If we remove the support for regular, non-bitmap, index scans with GIN,
that could be cleaned up as well. Even if we don't do that, gingetbitmap
should not error when the bitmap becomes lossy, but just return the
lossy bitmap.
Changes since 28.2
(http://archives.postgresql.org/message-id/499b0f
On Mon, Mar 2, 2009 at 3:02 PM, Jeff Davis wrote:
> On Mon, 2009-03-02 at 21:14 +0200, Heikki Linnakangas wrote:
>> If I'm reading the code correctly, item pointers of all matching heap
>> tuples are first collected into a TIDBitmap, and then amgetnext returns
>> tuples from that one by one. If th
On Mon, Mar 2, 2009 at 2:14 PM, Heikki Linnakangas
wrote:
> While reading the GIN code, I just rediscovered that the GIN partial match
> support suffers from the same problem that I criticized the "fast insert"
> patch about, and searching the archives I found that I already complained
> about tha
On Mon, 2009-03-02 at 21:14 +0200, Heikki Linnakangas wrote:
> If I'm reading the code correctly, item pointers of all matching heap
> tuples are first collected into a TIDBitmap, and then amgetnext returns
> tuples from that one by one. If the bitmap becomes lossy, an error is
> thrown. gingetb
While reading the GIN code, I just rediscovered that the GIN partial
match support suffers from the same problem that I criticized the "fast
insert" patch about, and searching the archives I found that I already
complained about that back in April:
http://archives.postgresql.org/pgsql-patches/
10 matches
Mail list logo
